Subject: [secdir] review of draft-ietf-dnsext-dnssec-gost-05

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jan 2010 14:38:14 -0500

I reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Since several SECDIR members are reviewing 
draft-ietf-dnsext-dnssec-gost-05 I have chosen to focus on one aspect 
of the document, i.e., the statement that support for GOST algorithms 
is a SHOULD (Section 6.1) for all DNSSEC aware implementations. I 
think this is an inappropriate characterization for the level of 
support that ought to be accorded an algorithm of this type. I 
explain my rationale for this assertion below.

GOST is an example of what I would term a "national" crypto 
algorithm. I characterize an algorithm as "national" if use of the 
algorithm is mandated by a government (within its sphere of 
influence, for some or all application contexts), but the algorithm 
otherwise is not widely adopted. The GOST set of algorithms are one 
such example. Others (chosen form the space of symmetric algorithms) 
include Camellia (Japan), SKIPJACK (US), SEED (Korea), and SMS4 
(China, for WAPI). AES and DES are not "national"  algorithms.  Even 
though they were published by NIST as FIPS, both were very widely 
adopted outside of the national context in which use is (was) 
mandated. This illustrates that the designation of an algorithm as 
"national" can change over time.

Other IETF WGs (e.g., IPsec, S/MIME, OPGP, and TLS) have adopted a 
policy of publishing RFCs that describe how to use one or more 
national algorithms in the context of a protocol. However, in these 
WGs, support for the algorithm is optional, i.e., a MAY in RFC 2119 
parlance. These RFCs define how to use a national algorithm IF one 
chooses to implement it. They do not require support for the 
algorithm by making it a SHOULD or MUST. This approach allows the 
IETF to publish RFCs that deal with a wide range of crypto algorithms 
(national and otherwise) without prejudice, without engaging in a 
protracted debate about whether all of these algorithms are equally 
"worthy" etc. These WGs also define a small number of mandatory (MUST 
or SHOULD), non-national algorithms, to promote interoperability.

I think the convention adopted by other WGs is appropriate for DNESEC 
as well. As a result, I suggest that this document be modified to 
specify support for GOST algorithms as a MAY.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Jan 2010 17:28:09 -0500

Hi,

I want to emphasise two things, before my question:

    1.  I'm not the shepherd for this document, but I'm asking this
    question in my capacity as co-Chair, such that I might ask
    something (or not ask) of document editors based on the response.

    2.  I super-really-I-mean-it don't have a strong opinion on this
    matter yet.

On Thu, Jan 07, 2010 at 02:38:14PM -0500, Stephen Kent wrote:

> policy of publishing RFCs that describe how to use one or more national 
> algorithms in the context of a protocol. However, in these WGs, support 
> for the algorithm is optional, i.e., a MAY in RFC 2119 parlance. These 
> RFCs define how to use a national algorithm IF one chooses to implement 
> it. They do not require support for the algorithm by making it a SHOULD 
> or MUST. This approach allows the IETF to publish RFCs that deal with a 
> wide range of crypto algorithms (national and otherwise) without 
> prejudice, without engaging in a protracted debate about whether all of 
> these algorithms are equally "worthy" etc. These WGs also define a small 
> number of mandatory (MUST or SHOULD), non-national algorithms, to promote 
> interoperability.

I get this argument.  The worry I have has something to do with either
the protocol environment or the use cases of the analogue protocols
you've picked.

In the case of IPsec and TLS, I believe (and I'm totally prepared to
be corrected) that there is a negotiation mechanism in place between
end points.  If I'm right about that, there's a serious disanalogy
here, because there's no possible way to make that negotiation work in
DNS (because of caches, and the way they might affect results).
That's perhaps unfortunate, but it's the protocol as we have it.

In the case of OPGP and S/MIME, the issue is different: these are
mostly protocols for people communicating with one another inside some
web of trust.  (I know, I know, S/MIME isn't like that, but it
immediately is in case we're using limited-deployment algorithms.)
The disanalogy here is different, but it has a similar force: if we
are going to continue to maintain the position that there's a global
DNS that's a universal service, then we have to discourage
non-implementation of algorithms that will freeze people out.

I've done my best to present above, as succinctly as possible, the
arguments against your argument.  I don't know that I've done their
partisans justice, but I'm trying to weigh each side.  So I'd
appreciate it if

    (1) those who agree with Steve could make their best arguments
    supporting his (do we need the secdir list for this?  Feel free to
    forward this, and you can direct replies to me for summary if
    desired)

and 
    
    (2) those who think I've made a weak case to follow up with
    stronger arguments.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Jan 2010 09:07:24 -0500

Andrew,

I think the arguments I made are not so tightly related to the 
question of the ability of the protocols in question to negotiate 
algorithms, but I do appreciate the questions you posed.

You are correct that IPsec peers and TLS clients & servers perform a 
negotiation prior to establishing a session or secruity association. 
However, TLS is the most widely deployed and used crypto protocol in 
large part because the set of algorithms that MUST be supported to 
ensure very wide interoperability is very small, despite the fact 
that many algorithms have been defined to use with TLS.

For S/MIME and OPGP there is a requirement that, ultimately, the 
receiver has some way to verify the cert associated with the sender. 
However, it is common for senders to sign messages that are send to 
mailing lists where the sender has no way of knowing what algorithms 
all the receivers support. So, your analysis for this case is off the 
mark. (Your analysis is applicable to the case of encrypted e-mail, 
because the sender has to retrieve certs for all recipients first, 
and thus can determine what algorithms, they support. But, signed 
e-mail is MUCH more common than encrypted e-mail in the public 
Internet.)

I understand the arguments you are making, and I agree that there are 
differences between protocols that may be used in closed communities 
vs. ones that are intended to have global scope, like DNSSEC. But, I 
think the argument I made is valid.

My point is that it is unreasonable to require every DNSSEC 
implementation to support every public key signature and hash 
algorithm that anybody chooses to register. This is a classic case of 
what economists call externalization of costs. By calling for such 
support for any national algorithm suite (or any algorithms that 
might be put forth and which are not widely employed), one 
establishes a bad precedent. Rather it makes sense to have a very 
limited number of algorithm suites that MUST (or SHOULD) be 
implemented. My recommendation is to limit mandated (MUST or SHOULD) 
support to just two: current and next.

BTW, we have had this discussion in SIDR, where the RPKI has a 
similar global scope and where Vasily had made a similar request for 
recognition of GOST algorithms. So far, that WG has said no, for the 
reasons I cited in my comments and above. The current plan there is 
to go with the two suite model I described above.

Steve

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jan 2010 09:44:31 -0500

On Fri, Jan 08, 2010 at 09:07:24AM -0500, Stephen Kent wrote:
> mailing lists where the sender has no way of knowing what algorithms all 
> the receivers support. So, your analysis for this case is off the mark. 

This is a good point.  Thanks.

> Rather it makes sense to have a very limited number of algorithm suites 
> that MUST (or SHOULD) be implemented. My recommendation is to limit 
> mandated (MUST or SHOULD) support to just two: current and next.

Hrm.  Well, we already violate this recommendation, I think, but I
take your point.

> BTW, we have had this discussion in SIDR, where the RPKI has a similar 
> global scope and where Vasily had made a similar request for recognition 
> of GOST algorithms. So far, that WG has said no, for the reasons I cited 
> in my comments and above. The current plan there is to go with the two 
> suite model I described above.

Ok.  Thanks for this; it's useful feedback.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Jan 2010 08:12:29 -0800

To take it one step further: a signing algorithm that is easily broken opens up a new attack vector. Imagine that all DNSSEC "client" implementations (resolvers) need to support two algorithms, A and B. If A and B are of actual equal strength, an attacker has an equal problem. However, if B is found to have weaknesses that allows an attacker to forge signatures, that attacker then can create a bogus chain to a trust anchor using B in the entire path.

It is for this reason that DNSSEC does not, for example, require that resolvers MUST be able to validate RSA signatures with 256-bit keys. However, by saying that resolvers MUST be able to validate anything other than the widely-agreed-to algorithms, you are opening up such an attack.

GOST signatures use a hash algorithm that has a known academic attack. Thus, even if the GOST asymmetric encryption algorithm is as strong as RSA with the size of keys that people are using, the overall signing algorithm may be weaker. This is *not* an argument that Russia should not use GOST: they have made their own security decisions based on the same knowledge that we have (and possibly more). It is, however, an argument against making everyone else be able to verify GOST signatures as if they were equivalent to other mandatory-to-implement signature algorithms.

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 08 Jan 2010 11:35:28 -0500

I am in full agreement with the arguments Paul and Steve have made.

Keep GOST as MAY.

Quoting Paul Hoffman <[email-masked]>:
> To take it one step further: a signing algorithm that is easily 
> broken opens up a new attack vector. Imagine that all DNSSEC "client" 
> implementations (resolvers) need to support two algorithms, A and B. 
> If A and B are of actual equal strength, an attacker has an equal 
> problem. However, if B is found to have weaknesses that allows an 
> attacker to forge signatures, that attacker then can create a bogus 
> chain to a trust anchor using B in the entire path.
>
> It is for this reason that DNSSEC does not, for example, require that 
> resolvers MUST be able to validate RSA signatures with 256-bit keys. 
> However, by saying that resolvers MUST be able to validate anything 
> other than the widely-agreed-to algorithms, you are opening up such 
> an attack.
>
> GOST signatures use a hash algorithm that has a known academic 
> attack. Thus, even if the GOST asymmetric encryption algorithm is as 
> strong as RSA with the size of keys that people are using, the 
> overall signing algorithm may be weaker. This is *not* an argument 
> that Russia should not use GOST: they have made their own security 
> decisions based on the same knowledge that we have (and possibly 
> more). It is, however, an argument against making everyone else be 
> able to verify GOST signatures as if they were equivalent to other 
> mandatory-to-implement signature algorithms.
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jan 2010 13:22:19 -0500

On Fri, Jan 08, 2010 at 08:12:29AM -0800, Paul Hoffman wrote:

> It is for this reason that DNSSEC does not, for example, require
> that resolvers MUST be able to validate RSA signatures with 256-bit
> keys. However, by saying that resolvers MUST be able to validate
> anything other than the widely-agreed-to algorithms, you are opening
> up such an attack.

Now, this is an interesting point.  I think if one combines this
argument with Steve's point that a certain baseline of mandatory
algorithms should be required _only_ because you need some common set
for interoperability, one has a pretty good argument that most
algorithms should be MAYs and not stronger.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Jan 2010 10:36:48 -0800

At 1:22 PM -0500 1/8/10, Andrew Sullivan wrote:
>Now, this is an interesting point.

Thank you. However, it is far from original.

>I think if one combines this

Bingo. If there is an algorithm that the technical community thinks is the "next" mandatory algorithm, you might want to make it "SHOULD+", but even that proposal is not always clear-cut.

<cue the peanut gallery>

---

From: David McGrew <[email-masked]>
Date: Fri, 8 Jan 2010 13:10:14 -0800

I also agree with the compelling reasons that Steve and Paul have  
articulated.

I'm confused about one point, though.  The IANA considerations section  
in draft-ietf-dnsext-dnssec-gost-06 asks for GOST R 34.10-2001 and  
GOST R 34.11-94 to be registered as OPTIONAL.  Was there some  
suggestion to make them mandatory?

David

On Jan 8, 2010, at 8:35 AM, Uri Blumenthal wrote:

>> broken opens up a new attack vector. Imagine that all DNSSEC  
>> "client" implementations (resolvers) need to support two  
>> algorithms, A and B. If A and B are of actual equal strength, an  
>> attacker has an equal problem. However, if B is found to have  
>> weaknesses that allows an attacker to forge signatures, that  
>> attacker then can create a bogus chain to a trust anchor using B in  
>> the entire path.
>>
>> anything other than the widely-agreed-to algorithms, you are  
>> opening up such an attack.
>>
>> attack. Thus, even if the GOST asymmetric encryption algorithm is  
>> as strong as RSA with the size of keys that people are using, the

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Jan 2010 15:20:13 -0600

> I also agree with the compelling reasons that Steve and Paul have  

+1

> suggestion to make them mandatory?

"
6.1.  Support for GOST signatures

   DNSSEC aware implementations SHOULD be able to support RRSIG and
   DNSKEY resource records created with the GOST algorithms as
   defined in this document.
...
8.  IANA Considerations
...
                                     Zone    Trans.
   Value  Algorithm         Mnemonic Signing Sec.  References   Status
   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
...
   Value   Algorithm        Status
   {TBA2}  GOST R 34.11-94  OPTIONAL
"

Section 6.1 and 8 are in conflict.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 09 Jan 2010 08:57:01 -0800

I agree as well.

-Ekr

At Fri, 08 Jan 2010 11:35:28 -0500,

---

From: Stephen Kent <[email-masked]>
Date: Sun, 24 Jan 2010 14:14:07 -0500

At 9:33 PM +0300 1/23/10, Basil Dolmatov wrote:
>Andrew Sullivan ÔË¯ÂÚ:
>>
>>>BTW, we have had this discussion in SIDR, 
>>>where the RPKI has a similar global scope and 
>>>where Vasily had made a similar request for 
>>>recognition of GOST algorithms. So far, that 
>>>WG has said no, for the reasons I cited in my 
>>>comments and above. The current plan there is 
>Andrew, I, being the participant in the quoted 
>process, want to share my description of what 
>had happened and I think that it will differ to 
>some extent.
>
>I noted that RPKI and SIDR implementations 
>having exactly no possibility to support 
>different protocols will definitely meet the 
>problems, which DNSSec is overcoming simply by 
>its design.
>
>Steve, in his presentation showed the technology 
>which gives possibility to given AS (or group of 
>ASes) to build entirely independent system of 
>distribution of routing information from the 
>outer world. That was _the_other_way_ to handle 
>possible protocol problems, just to present 
>mechanism, which allows to split whole system 
>into several entirely independent protocol 
>domains.
>
>Comparing to DNS the IDR ideology is entirely 
>different: DNS is wholistic and united service, 
>but main IDR principle is the independence of 
>routing decisions for any given AS.
>
>I also noted then that from my point of view the 
>DNSSec protocol approach seems much more 
>productive for the development of the network as 
>a whole and maintaining its integrity, SIDR 
>approach from that perspective seems a 
>restrictive one and leading to the dead end in 
>the near future.
>
>I would be very cautious when considering the 
>borrowing of the technologies and approaches 
>from SIDR to any other protocols and services, 
>these technologies though allowing to "overcome" 
>possible protocol problems in fact will lead to 
>the network split.
>
>dol@

Basil,

I agree that there are differences between the 
DNS and RPKI contexts, but we disagree on the 
principle common aspects associated with how to 
accommodate multiple algorithms in both 
environments.

The question for both DNSSEC and SIDR/RPKI is how 
many algorithms relying parties MUST/SHOULD be 
required to implement, and how do we. The 
approach adopted (so far) in the SIDR context is 
to minimize such requirements, to not burden RPs, 
and to avoid creating the sort of potential 
security problems cited by Paul Hoffman. Thus the 
plan is to mandate support for two sets of 
algorithms (we have only one set so far), a 
current MUST implement and a next MUST implement.

I believe that the situation for DNESEC is 
equivalent, i.e., imposing a requirement (via 
MUST or SHOULD) to support more than a current 
and next set of algorithms is not justifiable. It 
imposes unacceptable costs on resolvers 
(analogous to RPs in the RPKI context) and may 
have adverse secruity implications. Such 
externalization of costs is a fundamentally bad 
approach, one that the IETF tries to avoid in 
analogous contexts in all areas.

It is fine for DNSEXT to allocate algorithm IDs 
to national algorithms like GOST, but it is not 
appropriate to mandate their support, for the 
reasons cited in my review.

Steve

---

From: Basil Dolmatov <[email-masked]>
Date: Sat, 23 Jan 2010 21:33:31 +0300

> Ok.  Thanks for this; it's useful feedback.
Andrew, I, being the participant in the quoted process, want to share my 
description of what had happened and I think that it will differ to some 
extent.

I noted that RPKI and SIDR implementations having exactly no possibility 
to support different protocols will definitely meet the problems, which 
DNSSec is overcoming simply by its design.

Steve, in his presentation showed the technology which gives possibility 
to given AS (or group of ASes) to build entirely independent system of 
distribution of routing information from the outer world. That was 
_the_other_way_ to handle possible protocol problems, just to present 
mechanism, which allows to split whole system into several entirely 
independent protocol domains.

Comparing to DNS the IDR ideology is entirely different: DNS is 
wholistic and united service, but main IDR principle is the independence 
of routing decisions for any given AS.

I also noted then that from my point of view the DNSSec protocol 
approach seems much more productive for the development of the network 
as a whole and maintaining its integrity, SIDR approach from that 
perspective seems a restrictive one and leading to the dead end in the 
near future.

I would be very cautious when considering the borrowing of the 
technologies and approaches from SIDR to any other protocols and 
services, these technologies though allowing to "overcome" possible 
protocol problems in fact will lead to the network split.

dol@

---

From: Basil Dolmatov <[email-masked]>
Date: Mon, 25 Jan 2010 07:35:17 +0300

Stephen Kent пишет:

Andrew Sullivan ÔË¯ÂÚ:

BTW, we have had this discussion
in SIDR,
where the RPKI has a similar global scope and where Vasily had made a
similar request for recognition of GOST algorithms. So far, that WG
has said no, for the reasons I cited in my comments and above. The
current plan there is to go with the two suite model I described
above.

Andrew, I, being the participant in
the
quoted process, want to share my description of what had happened and
I think that it will differ to some extent.

I noted that RPKI and SIDR implementations having exactly no
possibility to support different protocols will definitely meet the
problems, which DNSSec is overcoming simply by its design.

Steve, in his presentation showed the technology which gives
possibility to given AS (or group of ASes) to build entirely
independent system of distribution of routing information from the
outer world. That was _the_other_way_ to handle possible protocol
problems, just to present mechanism, which allows to split whole
system into several entirely independent protocol domains.

Comparing to DNS the IDR ideology is entirely different: DNS is
wholistic and united service, but main IDR principle is the
independence of routing decisions for any given AS.

I would be very cautious when considering the borrowing of the
technologies and approaches from SIDR to any other protocols and
services, these technologies though allowing to "overcome"
possible protocol problems in fact will lead to the network split.

dol@

Basil,

I agree that there are differences between the DNS and RPKI
contexts, but we disagree on the principle common aspects associated
with how to accommodate multiple algorithms in both
environments.

Yes, we do disagree in principles (see below).

The question for both DNSSEC and SIDR/RPKI is how many
algorithms
relying parties MUST/SHOULD be

I wondered why MUST and SHOULD are quoted together. I thought that it
is two _different_ modal verbs with _different_ meaning and _different_
implementation demands.

required to implement, and how do we.
The approach adopted (so far) in the SIDR context is to minimize such
requirements, to not burden RPs, and to avoid creating the sort of
potential security problems cited by Paul Hoffman. Thus the plan is to
mandate support for two sets of algorithms (we have only one set so
far), a current MUST implement and a next MUST implement.

I believe that the situation for DNESEC is equivalent, i.e.,
imposing a requirement (via MUST or SHOULD) to support more than a
current and next set of algorithms is not justifiable.

The situation in DNSSec is entirely different from SIDR:

Comparing to DNS the IDR ideology is entirely
different: DNS is
wholistic and united service, but main IDR principle is the
independence of routing decisions for any given AS.

The way that was chosen by SIDR developers is demanding to invent some
methods and technologies to prevent network from being split.

Thank you, Steve, you proposed one of the possible technologies which
makes that possible (at least makes a forthcoming split more or less
implicit).

That does not mean that this technology is the _good_ one. It means
that for the given set of circumstances this solution is
_the_only_possible_ one.

So, I quit the discussion in SIDR, not because of I was satisfied with
the technology and solutions, but because of I have understood how I
could maintain network interoperability even with this rigid technology
and have had more urgent tasks to perform.

I kindly ask to all participating parties do not try to castrate
flexible protocol design of DNSSec to the SIDR/RPKI rigid approach.

It imposes
unacceptable costs on resolvers (analogous to RPs in the RPKI context)

RPs - are not resolver analogues, but this is for another discussion.

and may have adverse secruity implications. Such externalization
of
costs is a fundamentally bad approach, one that the IETF tries to
avoid in analogous contexts in all areas.

Here is another difference od DNSSec from SIDR - most of the software
is open-source in DNSSec, so costs have been already distributed evenly.

As for proprietary realisations it seems to me the maintaining of the
cost/profit balance is the task of the management of the given
enterprise, and I am sure that they will do their work well.

It is fine for DNSEXT to allocate algorithm IDs to national
algorithms like GOST, but it is not appropriate to mandate their
support, for the reasons cited in my review.

I do agree that MUST set of algorithms should be very narrow and
limited generally speaking to those algorithms by which root zone is
signed.

As for the other algorithms, it seems to me that the main goal of DNS
system is the providing integral name service resolution. If one have
to perform some additional steps (install different resolver software,
include something and something) just to get access to the network
names on some part of the world, then the obvious next step will be to
point this different resolver to another root of the tree.

Maybe this is the way the DNS system will develop, but now I think that
the some effort to keep the DNS system united is justified.

dol@

Steve

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 25 Jan 2010 08:22:35 -0500

My humble opinion: GOST "MUST NOT" be "SHOULD", but "SHOULD" be "MAY". For
reasons Steve explained.

Quoting Basil Dolmatov <[email-masked]>:
>       Stephen Kent пишет:   Re: review of
> draft-ietf-dnsext-dnssec-gost-05 At 9:33 PM +0300 1/23/10, Basil
> Dolmatov wrote: Andrew Sullivan ÔË¯ÂÚ:
> Ok.  Thanks for this; it's useful feedback.    Andrew, I, being the
> participant in the quoted process, want to share my description of
> what had happened and I think that it will differ to some extent.
>
> approach seems much more productive for the development of the
> network as a whole and maintaining its integrity, SIDR approach from
> that perspective seems a restrictive one and leading to the dead end
> in the near future.
>
> with how to accommodate multiple algorithms in both environments.
> The question for both DNSSEC and SIDR/RPKI is how many algorithms
> relying parties MUST/SHOULD be   I wondered why MUST and SHOULD are
> quoted together. I thought that it is two _different_ modal verbs
> with _different_ meaning and _different_ implementation demands.
> required to implement, and how do we. The approach adopted (so far)
> in the SIDR context is to minimize such requirements, to not burden
> RPs, and to avoid creating the sort of potential security problems
> cited by Paul Hoffman. Thus the plan is to mandate support for two
> sets of algorithms (we have only one set so far), a current MUST
> implement and a next MUST implement.
> current and next set of algorithms is not justifiable.   The
> situation in DNSSec is entirely different from SIDR:
> independence of routing decisions for any given AS. The way that was
> chosen by SIDR developers is demanding to invent some methods and
> technologies to prevent network from being split.
> So, I quit the discussion in SIDR, not because of I was satisfied
> with the technology and solutions, but because of I have understood
> how I could maintain network interoperability even with this rigid
> technology and have had more urgent tasks to perform.
>
> It imposes unacceptable costs on resolvers (analogous to RPs in the
> RPKI context)   RPs - are not resolver analogues, but this is for
> another discussion.
> and may have adverse secruity implications. Such externalization of
>  Here is another difference od DNSSec from SIDR - most of the
> software is open-source in DNSSec, so costs have been already
> distributed evenly.
> support, for the reasons cited in my review.  I do agree that MUST
> set of algorithms should be very narrow and limited generally
> speaking to those algorithms by which root zone is signed.
>
> to perform some additional steps (install different resolver
> software, include something and something) just to get access to the
> network names on some part of the world, then the obvious next step
> will be to point this different resolver to another root of the tree.
>
> Maybe this is the way the DNS system will develop, but now I think
> that the some effort to keep the DNS system united is justified.
>
> dol@
>
> Steve
>
>

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 25 Jan 2010 17:18:11 -0500 (Eastern Standard Time)

> independent protocol domains.

I disagree with this characterization of Steve's presentation.  He 
presented a technique to allow a local determination of the authorization 
of routing information.  His technique was not a technique for 
distribution of routing information and was not independent from the 
outside world.  Note also that locally originated routing information and 
RPKI information would flow to the outside world without effect.

--Sandy
   (sidr chair)

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 25 Jan 2010 17:44:32 -0500 (Eastern Standard Time)

A few comments and requests for clarification in line.

--Sandy

On Mon, 25 Jan 2010, Basil Dolmatov wrote:

>                   global scope and where Vasily had made a similar request for
>                   reasons I cited in my comments and above. The current plan there is to
>                   go with the two suite model I described above.
>                     
> 
>
>       Andrew, I, being the participant in the quoted process, want to share my description of what
>       had happened and I think that it will differ to some extent.
>
>       I noted that RPKI and SIDR implementations having exactly no possibility to support different
>       protocols will definitely meet the problems, which DNSSec is overcoming simply by its design.
>
>       Steve, in his presentation showed the technology which gives possibility to given AS (or group
>       of ASes) to build entirely independent system of distribution of routing information from the
>       outer world. That was _the_other_way_ to handle possible protocol problems, just to present
>       mechanism, which allows to split whole system into several entirely independent protocol
>       domains.
>
>       Comparing to DNS the IDR ideology is entirely different: DNS is wholistic and united service,
>       but main IDR principle is the independence of routing decisions for any given AS.
>
>       I also noted then that from my point of view the DNSSec protocol approach seems much more
>       productive for the development of the network as a whole and maintaining its integrity, SIDR
>       approach from that perspective seems a restrictive one and leading to the dead end in the near
>       future.
>
>       I would be very cautious when considering the borrowing of the technologies and approaches from
>       SIDR to any other protocols and services, these technologies though allowing to "overcome"
> I agree that there are differences between the DNS and RPKI contexts, but we disagree on the principle
> common aspects associated with how to accommodate multiple algorithms in both environments.
> 
>       The question for both DNSSEC and SIDR/RPKI is how many algorithms relying parties MUST/SHOULD be
> 
> I wondered why MUST and SHOULD are quoted together. I thought that it is two _different_ modal verbs with
> _different_ meaning and _different_ implementation demands.
>       required to implement, and how do we. The approach adopted (so far) in the SIDR context is to
>       minimize such requirements, to not burden RPs, and to avoid creating the sort of potential security
>       problems cited by Paul Hoffman. Thus the plan is to mandate support for two sets of algorithms (we
>       have only one set so far), a current MUST implement and a next MUST implement.
> 
>
>       I believe that the situation for DNESEC is equivalent, i.e., imposing a requirement (via MUST or
>       SHOULD) to support more than a current and next set of algorithms is not justifiable.
> 
>       Comparing to DNS the IDR ideology is entirely different: DNS is wholistic and united service, but
>       main IDR principle is the independence of routing decisions for any given AS.

I'm not certain of your comparison here.  Certainly the independence of 
local decisions is a fundamental principal in BGP.  Do not DNS name 
servers make local decisions?  And DNS resolvers?

> 
> The way that was chosen by SIDR developers is demanding to invent some methods and technologies to prevent
> network from being split.

You will have to explain this further as I see nothing undertaken in sidr 
that would produce a network split or whose sole purpose is to prevent a 
network split.

> Thank you, Steve, you proposed one of the possible technologies which makes that possible (at least makes a
> forthcoming split more or less implicit).

Steve's approach demonstrated how it was possible to provide for a local 
determination of authorization for routing information.

It had nothing to do with algorithm support, which I thought was your 
focus.

> That does not mean that this technology is the _good_ one. It means that for the given set of circumstances this
> solution is _the_only_possible_ one.
> 
> So, I quit the discussion in SIDR, not because of I was satisfied with the technology and solutions, but because
> of I have understood how I could maintain network interoperability even with this rigid technology and have had
> more urgent tasks to perform.
> 
> I kindly ask to all participating parties do not try to castrate flexible protocol design of DNSSec to the
> SIDR/RPKI rigid approach.
>       It imposes unacceptable costs on resolvers (analogous to RPs in the RPKI context)
> 
>       and may have adverse secruity implications. Such externalization of costs is a fundamentally bad
>       approach, one that the IETF tries to avoid in analogous contexts in all areas.
> 
> Here is another difference od DNSSec from SIDR - most of the software is open-source in DNSSec, so costs have
> been already distributed evenly.

You will have to explain this point more.  What does open source 
development have to do with the cost of operating a secure system?  Part 
of the cost being externallized is the need to multiply sign and multiply 
verify the same information in multiple algorithms.  Each new globally 
mandated algorithm is a burden on all users, whether they are paying 
development costs or not.

> As for proprietary realisations it seems to me the maintaining of the cost/profit balance is the task of the
> management of the given enterprise, and I am sure that they will do their work well.
>
>       It is fine for DNSEXT to allocate algorithm IDs to national algorithms like GOST, but it is not
>       appropriate to mandate their support, for the reasons cited in my review.
> 
> I do agree that MUST set of algorithms should be very narrow and limited generally speaking to those algorithms
> by which root zone is signed.
> 
> As for the other algorithms, it seems to me that the main goal of DNS system is the providing integral name
> service resolution. If one have to perform some additional steps (install different resolver software, include
> something and something) just to get access to the network names on some part of the world, then the obvious next
> step will be to point this different resolver to another root of the tree.

I don't understand this argument either.  You agree that the algorithm set 
needs to be limited to those used by the roots.  If that is done, why then 
would it be necessary to point to a different root?

A limited mandated algorithm set exists, you agree that a limited set is 
good - what exactly is your complaint?

--Sandy

> 
> Maybe this is the way the DNS system will develop, but now I think that the some effort to keep the DNS system
> united is justified.
> 
> dol@
> 
> Steve
> 
> 
> 
>