Subject: Re: [dnsext] Cryptographic Algorithm Identifier Allocation for DNSSEC

From: Andrew Sullivan <[email-masked]>
Date: Tue, 1 Sep 2009 10:25:15 -0400

No hat.

On Tue, Sep 01, 2009 at 10:55:18AM +1000, Mark Andrews wrote:

> SHA256 was special because we had to teach the working group that
> new signature algorithms need to support both NSEC and NSEC3.

It was also special because those who decided they had "teach the
working group" didn't make that decision until after WGLC had closed,
at which point there was a threat of appeal.  Which is exactly my
point: the current state of affairs requires the entire machinery of
the IETF to spin into action every time we want to support a new
algorithm.  

>  SHA256 should not be seen as representative of the time it will
> take in future.

On what basis do you say this?  We don't even know yet whether during
IETF last call the SHA2 draft will not face a demand for the
restoration of the NSEC and NSEC3 alias strategy, since we nowhere
have a document that says "NSEC3 support is mandatory".  The fact is
that we're a WG that mostly maintains a mature protocol; this tends to
mean urgency for review &c. is not great.
 
> DNSEXT goes from one extreme to the other.  RR allocation was a
> example of that.  New procedures were defined and people complained
> that RR's take too long without even trying the new procedures.

They complain of that because they remember the old ways -- ways that
hung around for a long time because this WG was (and, I am frequently
told by other WG Chairs and IETF participants, still is) regarded as
obstructionist, unwilling to understand the uses to which people want
to put the protocol, and generally unhelpful.  We can do something
about that by making our procedures in this new area flexible to begin
with.  Otherwise, people will (again) dismiss us as hidebound control
freaks who are protecting our protocol turf rather than trying to help
the rest of the users of the Internet.  This is not my view -- I
understand the motivation for conservatism -- but we need to
appreciate that there is a widespread view of the DNS protocol people
that is roughly the one I describe.

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2009 10:04:22 +1000

> the IETF to spin into action every time we want to support a new

The timing wasn't great I will admit that.
 
> mean urgency for review &c. is not great.

We have documents that say NSEC3 is manditory if you want to use
this code point.  Anything a TLD is likely to pickup needs to support
NSEC3.  Validators, de-facto, need to support NSEC3 as that is what
the TLD's are using.  But we've had these arguement before.

We had a document that almost makes it manditory.
draft-ietf-dnsext-dnssec-bis-updates needs to be revived.

2.1.  NSEC3 Support

   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
   records for hashed denial of existence.  Validator implementations
   are strongly encouraged to include support for NSEC3 as a number of
   highly visible zones are expected to use it.  Validators that do not
   support validation of responses using NSEC3 will likely be hampered
   in validating large portions of the DNS space.

   [RFC5155] should be considered part of the DNS Security Document
   Family as described by [RFC4033], Section 10.

-- 
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, 2 Sep 2009 10:19:45 -0400

> draft-ietf-dnsext-dnssec-bis-updates needs to be revived.

Then participants in the WG need to put pressure on the document
editors to complete their work, in the form of concrete suggestions or
reviews that say, "Please publish this now."  If tomorrow we heard a
large number of reviews from participants that said, "The document is
done, please send it on now," the editors might be persuaded not to
make changes they're contemplating.  As things stand, the editors have
claimed (to me) that they think the document not ready for WGLC.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Sep 2009 08:45:36 +1000

> claimed (to me) that they think the document not ready for WGLC.

Then the document needs to be rev'd.  As a chair you need to see that
this happens.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Sep 2009 10:52:31 -0400

> Then the document needs to be rev'd.  As a chair you need to see that

I guess I wasn't clear, but as Chair I'm asking participants to post
_specific text_ that they want changed, or else to post a review
stating explicitly that the document is ready for publication.  We'll
never get movement with the slow pace of review we've had on this
document so far.  At one point, the WG decided to leave it as a
"living draft".  I usually think that's a bad idea anyway, but in this
case it's been fatal because there's been little urgency to finish it
up and put it to bed.

If there's clear interest in changes, then that will be helpful in
delivering a revision.  If there's clear interest in publication as
is, that will be a reason to go through WGLC and finish this off.  But
no chair can make any determination without evidence of the intent of
the WG, and that's what's missing at the moment.

Best,

A

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Sep 2009 08:05:27 +1000

I can cope with it still being a living document.  However that
requires that it be kept alive.  I'm also happy if we decide it is
time to say we have caught most of the problems and publish as a
RFC.

One of the DNS vendors is still currently in the process of adding
DNSSEC support.  This would be a good time for feedback on what we
got wrong so I would wait a little while more.

Mark