Subject: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required"

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jun 2009 15:56:25 -0700

Greetings again. Appendix A.1 in RFC 4034 has the initial list of algorithm types for DNSSEC. To add to that table, one needs a standards-track RFC. This means that an signature algorithm that cannot be embodied in a standards-track RFC, such as because it is not completely in English, cannot be used interoperably in DNSSEC. For example, this might prevent the GOST work the WG has taken on from being used if the eventual RFC is Informational instead of Standards Track.

This seems unnecessarily limiting. I am not aware of any other WG that requires a standards track RFC for allocating an identifier for a cryptographic specification. *Many* cryptographic specifications are described in Informational RFCs, and this has not been a problem for anyone.

Therefore, I propose that the WG take on a short revision to RFC 4034 that makes the one change of making assignments into the IANA registry for DNSSEC Algorithm Types be "RFC Published". In addition, it would allow IANA to pre-assign values based on requests from an Area Director. This would allow Internet Drafts that are proposing new signature algorithms to contain valid examples of records using the proposed algorithms.

--Paul Hoffman, Director
--VPN Consortium

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Shane Kerr <[email-masked]>
Date: Mon, 08 Jun 2009 11:30:47 +0200

Paul,

> Therefore, I propose that the WG take on a short revision to RFC 4034 that makes the one change of making assignments into the IANA registry for DNSSEC Algorithm Types be "RFC Published". In additi…

This makes sense to me.

--
Shane

---

From: [email-masked]
Date: Mon, 8 Jun 2009 09:55:12 +0000

> Therefore, I propose that the WG take on a short revision to RFC 4034 that makes the one change of making assignments into the IANA registry for DNSSEC Algorithm Types be "RFC Published". In additi…

	I'm pretty sure that the structure as outlined in Appendix A is fundamentally wrong.
	And i'm not sure I'm happy with the proposed relaxation.  Historically, the IETF
	has been comfortable incorporating other work by reference, without the intial hurdle
	that the work be structured/introduced/adopted as an IETF work.  

--bill

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 08 Jun 2009 11:55:28 +0200

Paul Hoffman wrote:
> In addition, it would allow IANA to pre-assign values based on requests from an Area Director. This would allow Internet Drafts that are proposing new signature algorithms to contain valid examples of records using the proposed algorithms.
> 

I don't disagree on the std vs inf. track change, but i'd rather see drafts use 
a specific algorithm identifier (i.e. 254 or 255) for their examples until the 
very very last moment when it is absolutely certain what numbers are assigned 
and that those won't change anymore.

(Yes i know, this is not what I myself have done last week. Do as I say, not as 
I do :p)

Jelte

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Jun 2009 07:07:48 -0700

>	that the work be structured/introduced/adopted as an IETF work. 

I think the examples of where such incorporation has happened *in standards track RFCs* are few and far between. The most common method for doing that are Informational RFCs, some of which come from WGs, some from individual submissions, some from independent submissions directly to the RFC Editor.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Jun 2009 15:46:26 -0700

At 6:00 PM -0400 6/8/09, Samuel Weiler wrote:
>On Fri, 5 Jun 2009, Paul Hoffman wrote:
>
>>This means that an signature algorithm that cannot be embodied in a standards-track RFC, ... not completely in English, cannot be used interoperably in DNSSEC.
>
>RFC4034 and its ancestors reserved two values (253 and 254) for "private" algorithms and specified ways to use multiple private algorithms without bad interactions.  While I doubt the code to do that is well-tested, presumably the code to use GOST in DNSSEC isn't well-tested, either.  Perhaps both could be debugged together.

I'm having a hard time parsing your statement. It sounds like "if GOST cannot be on standards track, people who want to use GOST can only identify it as 253 or 254". I certainly hope I am misinterpreting you...

>Some registries are Standards Action precisely because of the cost shifted to implementors when registrations are unchecked.  As an example, see the URI registry, RFC4395.  And that particular registry doesn't suffer from the eight-bit limit that we face here.

That's a bad analogy. I was an (unfortunately active) part of that decision, and the reason we made those labels require standards action is precisely because they were labels, not limited to a numberspace. There was competition for easily-identified URI scheme names ('tv', 'channel', and so on). No one competes for yet-another-number.

>Furthermore, this WG has been eating (slowly) into that eight-bit space for signaling the use of a Standards Track DNSSEC option and, given how well that signaling mechanism works, might do so again. The expired draft-ietf-dnsext-dnssec-trans-06 discusses the decision from the first time this was done.

I categorically reject the notion that there could be more than a hundred new signature mechanisms introduced in the next few decades. If we ever get beyond 150 (!), we will have plenty of time to come up with another scheme for sub-defining new algorithms.

Data point: even in crypto protocols where the signature algorithm identifiers are handed out like candy, there are fewer than 50 to date, and that includes many that have already been discarded. Can you show any evidence that we could possibly use four times that many, given that we would have a much higher bar (RFC required)?

We might want to take the "how many RFC-required signature algorithms" discussion to SAAG; they would have a better idea than the DNSSEC WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 8 Jun 2009 20:27:52 -0400 (EDT)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

On Mon, 8 Jun 2009, Paul Hoffman wrote:

>> RFC4034 and its ancestors reserved two values (253 and 254) for 
>> "private" algorithms and specified ways to use multiple private 
>> algorithms without bad interactions.  While I doubt the code to do 
>> that is well-tested, presumably the code to use GOST in DNSSEC 
>> isn't well-tested, either.  Perhaps both could be debugged 
>> together.
>
> I'm having a hard time parsing your statement. It sounds like "if 
> GOST cannot be on standards track, people who want to use GOST can 
> only identify it as 253 or 254". I certainly hope I am 
> misinterpreting you...

RFC4034 section A.1.1 describes how the private algorithm types work, 
which includes embedding longer algorithm identifiers in the DNSKEY 
and RRSIG data.  So one might say "if an algorithm does not have a 
unique algorithm number assigned, its use can be identified by the 
algorithm number 253 and the unique domain name X".

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 8 Jun 2009 18:00:50 -0400 (EDT)

On Fri, 5 Jun 2009, Paul Hoffman wrote:

> This means that an signature algorithm that cannot be embodied in a 
> standards-track RFC, ... not completely in English, cannot be used 
> interoperably in DNSSEC.

RFC4034 and its ancestors reserved two values (253 and 254) for 
"private" algorithms and specified ways to use multiple private 
algorithms without bad interactions.  While I doubt the code to do 
that is well-tested, presumably the code to use GOST in DNSSEC isn't 
well-tested, either.  Perhaps both could be debugged together.

> This seems unnecessarily limiting. I am not aware of any other WG 
> that requires a standards track RFC for allocating an identifier for 
> a cryptographic specification. *Many* cryptographic specifications 
> are described in Informational RFCs, and this has not been a problem 
> for anyone.

Some registries are Standards Action precisely because of the cost 
shifted to implementors when registrations are unchecked.  As an 
example, see the URI registry, RFC4395.  And that particular registry 
doesn't suffer from the eight-bit limit that we face here.

Furthermore, this WG has been eating (slowly) into that eight-bit 
space for signaling the use of a Standards Track DNSSEC option and, 
given how well that signaling mechanism works, might do so again. 
The expired draft-ietf-dnsext-dnssec-trans-06 discusses the decision 
from the first time this was done.

> Therefore, I propose that the WG take on a short revision to RFC 
> 4034 that makes the one change of making assignments into the IANA 
> registry for DNSSEC Algorithm Types be "RFC Published".

Given the limited code point space and the availability of 
alternatives (the private algorithm option), I oppose such a change.

-- Sam

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Jun 2009 10:54:00 -0700

At 8:27 PM -0400 6/8/09, Samuel Weiler wrote:
>  a non-subscriber, or because it was over 20K.    With the massive amount of spam, it is easy to miss and therefore   delete relevant posts by non-subscribers.   Please fix your subscription addresses. ]
>
>RFC4034 section A.1.1 describes how the private algorithm types work, which includes embedding longer algorithm identifiers in the DNSKEY and RRSIG data.  So one might say "if an algorithm does not have a unique algorithm number assigned, its use can be identified by the algorithm number 253 and the unique domain name X".

Again, I hope I'm misinterpreting you. It sounds like you are saying "algorithms with standards track RFCs are uniquely identified by a single octet; algorithms with an informational RFC must waste octets in every signature by including a domain name". Is that the tradeoff you want for your concern of us having 250 standards-track signature mechanisms (even though no other crypto protocol in the IETF has that many)?

--Paul Hoffman, Director
--VPN Consortium

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Jun 2009 16:48:47 -0400

After reading this reply over before sending it, I'm not sure I'm able to
keep apart my personal opinions, the opinion of the WG chair role I
have or the role of DNSSEC historian. Thus please read this as my
personal opinion not associated with my role as DNSEXT chair.

<no-hat>

At 18:56 05/06/2009, Paul Hoffman wrote:
>Greetings again. Appendix A.1 in RFC 4034 has the initial list of 
>algorithm types for DNSSEC. To add to that table, one needs a 
>standards-track RFC. This means that an signature algorithm that 
>cannot be embodied in a standards-track RFC, such as because it is 
>not completely in English, cannot be used interoperably in DNSSEC. 
>For example, this might prevent the GOST work the WG has taken on 
>from being used if the eventual RFC is Informational instead of 
>Standards Track.
>

This message is about adding new algorithms in general to DNSSEC.

DNS is an important infrastructure protocol, if it stops working
other things fail. For that reason until something in shown to be
HARMLESS we have standards action controlling admission. Good example is
the RRtype admission criteria used to be standards action, RFC2929
changed that to "IETF Consensus" and "Specification Required" , RFC5395
relaxed it to "Expert Review".

In DNS there is no handshake between "client" and "original server" 
to negotiate
the algorithm to use, either the client understands the "broadcast"
RRSIG or it does not. For this reason keeping the list of algorithms that
"clients" need to understand small is an interoperabilty advantage.

It takes much longer to upgrade installed software base than the
glacial phase of draft progressing through the working group + IESG,
thus the speed of allocation argument is not a compelling one.
If someone wants to experiment the private name spaces alg=253 and 254
are available. The private spaces IMHO are not suitable for production use.

We do not want to encourage "Vanity" algorithms, there should be a good
reason for adopting new algorithms. Having said that I think the next
algorithm we adopt (after RSA/SHA256) ought to be an Elliptic Curve
algorithm. Followed by the phasing out of DSA.

Due to the transport used by DNS we do not want to encourage/require
zones to use multiple DNSKEY algorithms to sign their zone. In
general only during transition from one algorithm to another should zone
be signed by multiple algorithms.
The more algorithms used ==> more signatures on each RRset ==> larger answers.

In the history of systems with "finite" number spaces we have a history of
running out of the space no matter how large the early adopters 
thought the space
was. Remember IPv4 addresses, DHCP option space, AS numbers, original Icelandic
tax id numbers [1], etc. etc. The moral is be conservative in allocations OR
before allocations are opened up have a reuse plan in place.

>registry for DNSSEC Algorithm Types be "RFC Published". In addition, 
>it would allow IANA to pre-assign values based on requests from an 
>Area Director. This would allow Internet Drafts that are proposing 
>new signature algorithms to contain valid examples of records using 
>the proposed algorithms.

I will strongly advocate against relaxing the allocation rule
until someone convinces me that relaxing it is harmless.
Same goes for new NSEC3 obfuscation algorithms.

         Olafur

[1] The number (8 digits actually 7 the last one was a check digit)
reflected the name of the person.
For each name there was a finite number space that based on the following
assumptions:

         - List of names was fixed as the government maintained a 
list of names that
                 were acceptable
         - distribution of names was going to be the same as it was
           just before the system was put in place.
         - Population would keep growing slowly
         - Life expectancy would not change
         - Number would only be used for tax identification

Guess what all of the assumptions were wrong, the situation got so bad that
numbers were reused in the same tax year.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Jun 2009 17:43:27 -0400

>algorithm. Followed by the phasing out of DSA.

I disagree with the previous paragraph.  For one, what is a "vanity" 
algorithm?  And what is a "good reason" to adopt?  I think the flaw 
in the logic above it that the choice of cryptographic system is not 
strictly a technical decision.  There are other factors involved, 
whether the factors run counter to an engineer's sensibilities or not.

One could argue that DSA is a "vanity" algorithm as very few zones 
use it and not one of the TLDs in the iTAR uses DSA.  I don't know of 
any zone that uses DSA - I bet there are some.  According to 
http://secspider.cs.ucla.edu/, there are 10 RSA/MD5 keys, 20 
DSA/SHA-1, and about 20,000 RSA/SHA-1.

I don't think it is up to the DNS Extensions WG to dictate policy 
regarding the use of cryptography.

>The more algorithms used ==> more signatures on each RRset ==> larger answers.

This is a red herring.  If it is the size of response that is a 
concern, then a zone should stick to one algorithm at a time - it 
doesn't matter which algorithm is used so long as the resolvers 
understand a range of algorithms.

There's a fear that resolver's won't be updated?  Maybe so, but it is 
in the interests of the resolver to keep up to date on this.  At the 
NIST Key Management Symposium, it was stated that cryptographic 
algorithms, like keys, wear out their welcome.

>The moral is be conservative in allocations OR

My take on the moral - especially with regards to IPv4 run out - is 
to build in a transition plan (to a larger name space).  The hang up 
with IPv4 and IPv6 is not that we are out of IPv4 addresses but that 
no one thought to include in IPv6 a transition mechanism.  The 
transition from 2-byte to 4-byte Autonomous System numbers hasn't 
been a major problem because, fortunately, the transition plan was 
able to fall into place.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Jun 2009 15:20:59 -0700

At 4:48 PM -0400 6/9/09, Olafur Gudmundsson wrote:
>HARMLESS we have standards action controlling admission.

Does this means that you are against the current SHA-256 document, which cannot be shown to be harmless? You have supported it in the recent past. We *know* that SHA-256 will get worse over time, and will need to have a transition away from it. Why the contradiction?

>In DNS there is no handshake between "client" and "original server" to negotiate

We fully agree. But that statement is irrelevant to whether or not an algorithm needs to be on standards track. No system needs to implement all standards track documents, as we all know.

>are available. The private spaces IMHO are not suitable for production use.

Section A.1.1 of RFC 4034 makes it quite clear that they are intended for production use.

>reason for adopting new algorithms.

Fully agree.

>The more algorithms used ==> more signatures on each RRset ==> larger answers.

Quite right. However, that is also irrelevant to whether or not something needs to be on standards track.

>running out of the space no matter how large the early adopters thought the space

As Sam Weiler pointed out, we already have one: Section A.1.1 of RFC 4034. You might change your view on whether or not that is suitable for production use (if we ever get there).

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Jun 2009 11:05:33 +1000

In message <[email-masked]>, Samuel Weil
> well-tested, either.  Perhaps both could be debugged together.

	Well tested?  It's not even written and won't be until there
	is a need to write it.  At the moment we treat all "private"
	algorithms as unknown.  Unless you need to print the
	algorithm's name in a comment or you are trying to verify
	completeness in signing there is no need to examine it until
	you support crypto algorithms which use it.
 
	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Jun 2009 11:24:27 -0400

[Chair hat on]

Dear colleagues,

I am hanging my message on the interchange between two
participants, but this is an instance of metonymy.  I am not
encouranging that we divide into "camps", but trying to illustrate a
spectrum of options.

On Tue, Jun 09, 2009 at 05:43:27PM -0400, Edward Lewis wrote:
> algorithm?  And what is a "good reason" to adopt?  I think the flaw in 
> the logic above it that the choice of cryptographic system is not  

[…]

> regarding the use of cryptography.

I wish to draw the WG's attention to the above difference of opinion,
and encourage participants to come to some workable compromise about
the issue, assuming the WG decides to go ahead with the proposed new
charter (or something like it).  If we are going to take on
maintenance work for DNSSEC algorithms, then we might like to have
some principles (I am reluctant to establish "rules" this early in the
process) upon which we will base the decision to take a given
maintenance action.

At one end of a spectrum of principles is something like the one
Olafur outlines (and with which, I suspect, Sam is in agreement): no
action unless there's some compelling reason, with a high barrier to
algorithm ID assignment.

The other end of the spectrum is something like the one Ed (and, I
think, Paul Hoffman) suggests: it's none of our business what people
want to do with this stuff, and unless there's a compelling reason _not_
to hand out an assignment, we ought to allow them to go ahead. 

There are some related issues, but I'd like to focus on the above
dichotomy for a moment.

If we work under a charter that makes us responsible for the algorithm
number assignments, then we do two things:

    1.  We undertake to look after "the interests" of the DNSSEC
    algorithm space under the DNSSEC parts of the DNS protocol.

    2.  We undertake to look after "the interests" of the wider
    Internet community with respect to DNSSEC and algorithm number
    assignments.  

It is plain that these two undertakings are not automatically in
harmony (although one can of course construct an argument about how
they converge in the long run).  Therefore, I think it would be
beneficial if we thought hard about the tension between those two
tasks, and try to expose the ways in which they can be broadly
reconciled.

An alternative, of course, is to refuse to change the charter
specifically to include DNSSEC algorithm maintenance.  It isn't clear
to me what the effect of that would be, however, since the existing
charter in any case makes us responsible for DNS maintenance in
general, and DNSSEC algorithms would seem to fall under that category.

If you have an opinion on where on the spectrum of principles the WG
ought to fall, I think it would be good to hear about it.  These
expressions might also be helpful to the rest of the IETF in
evaluating our proposed new charter.

Best regards,

Andrew

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 10 Jun 2009 16:52:22 +0100

> general, and DNSSEC algorithms would seem to fall under that category.

Apologies if I have missed this and it has been said before, but I
think there is a qualitative difference between:
 a) maintaining algorithm registries used in an environment where
    support of those algorithms is optional and can be negotiated
    between sender and receiver; and
 b) maintaining algorithm registries where it makes support of
    an algorithm is in effect compulsory (i.e. if they are not
    supported by one party, there will be interoperability
    problems e.g. because of lack of algorithm negotiation).

For algorithm registries falling into camp (a), provided the use
is by some measure sensible, and subject to Bill's (I think)
comments about every registry we think is inexhaustible actually
coming close to exhaustion after a few years, I think there should
in general be an open minded approach to handing out entries.

For algorithm registries falling into camp (b), the hurdle must be
set higher. It is not simply a technical evaluation of the merits
of one algorithm in isolation. We also need to be concerned about
implementation bloat (as in effect every implementation needs
to support every algorithm), and far more careful about IPR burdened
algorithms, for instance.

There may also be shades of grey in between.

This is not a statement about the GOST application, but a general
statement.

-- 
Alex Bligh

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 10 Jun 2009 12:02:36 -0400

At 18:20 09/06/2009, Paul Hoffman wrote:
>Does this means that you are against the current SHA-256 document, 
>which cannot be shown to be harmless? You have supported it in the 
>recent past. We *know* that SHA-256 will get worse over time, and 
>will need to have a transition away from it. Why the contradiction?

If I had not been chair of the WG I would have argued against it
and told people to wait until the new generation of digest algorithms
is available.
WG can still kill it if knowledgeable people make arguments
that it is not needed or is harmful.
IESG may reject it as well if they do not like it.

>We fully agree. But that statement is irrelevant to whether or not 
>an algorithm needs to be on standards track. No system needs to 
>implement all standards track documents, as we all know.

While your last statement is in theory true. In reality it is not,
implementations either have policies like "We implement all DNS RFC's"
(this is the case of Nominum, ISC and NLnetLabs).
If they did not there are still going to be customers that say
"I need algorithm X implement it" and if that is a paying customer it
is hard to say no.

>intended for production use.

I think we need to define what production means, you can use a 
Private algorithm  in your in house network and that is "in production",
what I meant was in "full Internet use".

I do not read A.1.1 to mean full Internet use nor does it say 
"experiment only".
All it does say is "if you understand this number then the next field 
is going to
be an identifier of this type, If you support that identifier you know how to
parse the key"

> >reason for adopting new algorithms.

(glad there is something we agree on :-) )

>Quite right. However, that is also irrelevant to whether or not 
>something needs to be on standards track.

Please give me any other reasons than "ease of registration" or
"number space is large no need to worry" for relaxing the requirement.

>As Sam Weiler pointed out, we already have one: Section A.1.1 of RFC 
>4034. You might change your view on whether or not that is suitable 
>for production use (if we ever get there).

Actually it is A.1 that contains the possible escape hatch (algorithm 
0 or 255)
I hope that DNS is obsoleted before we need to worry about using the
escape hatch.

         Olafur