[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implied NSEC3 support in rsasha256 (was: [dnsext] Re: Working Group Last Call for draft-ietf-dnsext-dnssec-rsasha256-05)
On Dec 10, 2008, at 10:16 AM, Andrew Sullivan wrote:
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.
Since, as far as I can recall, RFC 5155 didn't change anything in the
previous RFCs, it didn't warrant a statement saying that it updated
any. Which is why it doesn't.
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.
Um, what? I'm not at all certain how you got the impression that "the
objection against linking the implementation ... has considerable
force in terms of the protocol documents".
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.
OK, I guess.
I'll admit that the intent that all future algorithms would imply
understanding of NSEC3 (or, you know, the entire DNSSEC standard)
wasn't captured in the NSEC3 RFC. I suppose that is, to some degree,
my fault. I may have insisted that the document focus only on what
NSEC3 was and how to implement it, rather than including instructions
to the working group.
However, I remember fairly clearly that our intent when working on
NSEC3 was to have future algorithms imply support for both NSEC and
NSEC3. And that we would handle this when we allocated the next
algorithm. Which is now.
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.
Fair enough. Jelte's proposed text looks pretty good to me.
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.
For the record, I strongly favor option #1.
"Delay deployment"? This may delay *publication*. It is a bit of a
stretch to say that we are delaying deployment. You could deploy now,
if you so wished. If you need the imprimatur that getting the
document through the glorious IETF process gives to deploy, I would
suggest that you are in no rush.
--
David Blacka <davidb@verisign.com>
Sr. Engineer Platform Product Development
--
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/>