Re: implied NSEC3 support in rsasha256 (was: [dnsext] Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05)

[Andrew Sullivan <ajs@shinkuro.com>]

Dear colleagues,

I recognise that there are several people who are unhappy with the
current text of draft-ietf-dnsext-dnssec-rsasha256-09.  

We have a few options:  

1.  Withdraw the request for publication (and, presumably, either come
    to some new agreement or abandon the effort).

2.  Hash this out during IETF last call.  

3.  Accept the document as it stands, with the compromise it contains;
    if we do this, we can also take the further action of preparing things
    so that next time, we don't have to alias the identifiers.

I think the second option imposes on the whole IETF a burden it
shouldn't have to face: we should have settled this in the WG.
(Plainly, I thought we had, or I wouldn't have sent the document
along.)  Therefore, from my point of view, the options are (1) or
(3).  If it appears to me that my earlier determination of consensus
was in error and no compromise is forthcoming, I'll default to option
(1).  

If you examine the discussion about this issue prior to the change,
you'll observe that the reasoning for it was simple: the single
identifier required that implementers not support one new feature
(SHA-2), but that they also accept a different feature (NSEC3).

I think it is entirely fair to observe that validators that don't
support NSEC3 are going to be more or less useless in future.  From a
process point of view, however, a naive implementer doesn't have a way
to learn that: RFC 5155 does not say that it updates any of the
DNSSECbis RFCs.  Perhaps it should, but it doesn't today.

Therefore, it seems to me that the objection against linking the
implementation of new algorithms with the implementation (or at least
recognition) of a new RRTYPE has considerable force in terms of the
protocol documents, even though the practical effect is blunted.  The
responses to this so far have suggested that NSEC-only implementers
don't need to implement NSEC3; this is true, but they have to
_recognize_ it.  That is is still a technical burden, and one that we
have nowhere else announced is necessary.

I think it would be a good idea to tell people that future algorithm
assignments will not alias the identifiers.  A good place to do that
would be in the dnssec-bis-updates document.  We have an urgent need
to complete that document anyway, because that's where the discussion
about different trust anchors is supposed to go.

If we insist on unifying the identifiers for these algorithms in
draft-ietf-dnsext-dnssec-rsasha256, rather than using aliases, then in
my opinion we need text for the document that explains the decision in
considerably greater depth, since even (some) readers knowledgable in
this area found the link perplexing when they reviewed the document.

I therefore ask those currently objecting to the algorithm aliasing
whether they can live with the current arrangement, with the proviso
that we will do something about this in dnssec-bis-updates.  (This is
option 3.)  I also ask those who object to the current text, and who
cannot support option 3, to state explicitly that they'd rather delay
deployment of SHA-2 than live with this compromise.

At the same time, I ask those who objected to the -05 text during WGLC
if they could live with putting the old -05 text back in, as long as
there was additional text explaining why the change.  (This is option
1.)  It would be very nice if you had proposed text to add, as well.
Note that the upshot of this will be a new draft with a substantive
change.  I therefore believe it will require another WGLC.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

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