[dnssec-deployment] [smb at cs.columbia.edu: how to phase in new hash algorithms?]

[Sam Weiler]

[Removed the US Gov't WG on DNSSEC roll out <usg-dnssec at shinkuro.com>
from the CC line.  Why was that list added anyway?]

> I think there's often situations where a person can do a stellar job of 
> writing up an issue without being the person who raised it.

As my initial reply to Doug indicated, I'm not completely sure what
he's concerned about.  Unless one understands that, it's difficult to
write text to address it.  I (and others, including Olaf) have
attempted to speculate about his concerns and answer our own
speculations, but there's a limit to how useful that is. 

If there's really something that the current docs are unclear about, I
still think it would be more productive to let a fresh hand try to
write something better rather than turning again to the folks who
wrote the unclear text. 

> Well, perhaps I'm misunderstanding this, but I don't see how it makes 
> sense to use a new hash algorithm in creating a signature before any of 
> the resolvers can check it.  

For an example of where this could be useful, see David Blacka's
DNSSEC Experiments draft.
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-00.txt

> Doesn't that effectively mean the signature 
> is uncheckable?  What's the transition process?

Yes, but an uncheckable RRSIG does no harm besides adding bits to an
answer -- an RRset can have multiple signatures.  I believe all of
this is throughly discussed in the (truly wonderful and quite
readable) DNSSECbis documents and Olaf and Miek's DNSSEC Operational
Practices doc, and I'm not sure I see the value in revisiting all of
it in detail here. 

-- Sam