[Dnssec-deployment] Starting with SHA1?

[Chris Thompson]

On Jul 27 2010, Edward Lewis wrote:

>At 22:43 +0100 7/26/10, Chris Thompson wrote:
>
>>That's NSEC3-RSASHA1
>
>I gave a talk where I recommended "not starting with SHA1" - in that 
>we have SHA256 available now.

I don't know whether it is VeriSign or Educause who have chosen that
signing algorithm for "edu". And as it still has obscured DNSKEYs,
they could easily be planning to change it before going live anyway.

>Operator-to-operator (as opposed to messing with status levels in the 
>IANA registry as governed by the IETF), should a newly signed zone go 
>with SHA256 (or SHA512) and bypass SHA1?
>
>I hope to squeeze in a roll from SHA1 to SHA256 in US just to "be 
>(more) modern."

Regardless of the arguments about the status of different signing
algorithms in I-D draft-ietf-dnsext-dnssec-registry-fixes, the fact
that the root zone uses RSASHA256 has forced the issue here:
everyone has to support it PDQ now.

If I was signing a new zone now I would use RSASHA256, especially
if my intention was to advertise its keys only via a DS chain from
the root. It's not significantly more expensive, and may just
*possibly* be significantly more secure. "More modern" isn't
really relevant.

Algorithm rollover for an existing large active zone is something
one wants to put off until it's really necessary though, because
of the size-doubling during the overlap period when it has to be
signed with both algorithms. (I can't help feeling that the
constraints of RFC 4035 [section 2.2, last paragraph] might
have been avoided by a bit more work on the protocol.)

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 at ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.