[dns-operations] .edu domain algorithm recommendation

[Michael Sinatra]

On 08/16/10 14:00, Sue True wrote:
>
> I wonder what's the algorithm to use to generate keys? We have several
> top level .edu domains which are ready to get signed, I want to make
> sure the right algorithm is used, while check some of the singed .edu
> zones, the algorithms used are different, for example:
>
> internet2.edu: 7 RSASHA1-NSEC3-SHA1
> lsu.edu : 8 RSA/SHA-256
> penn.edu : 5 RSA/SHA-1

FTR:
ucb.edu: 10 RSASHA512
ucberkeley.edu: 10 RSASHA512 (in the process of migrating)
berkeley.edu: will be 10 RSASHA512


> I am thinking to use Algorithm 7 to generate the keys, but on section
> 2.2 of this draft:
>
> http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-registry-fixes-06
>
> 7 and 8 are both RECOMMENDED, only 5 is REQUIRED, is it safe to use just
> algorithm 7, and not 5?
>
> The Quickstart guide for .gov Zone seems to think that it's okay to use
> 7 alone.

First, you should make sure you fully understand the differences between 
NSEC and NSEC3 and the implications thereof.  It's probably a debatable 
point, but NSEC3 is mainly useful for registries, where the opt-in 
feature is important.  If you want to prevent zone enumeration, you also 
want NSEC3.  I regard our DNS as a public database (like the phone 
book), so I choose NSEC.

The other issue is the signing algorithm.  Although there are 
theoretical collisions in the SHA1 hash, actually exploiting these in a 
DNSSEC environment would be sufficiently hard to make it not worth 
worrying about.

The counterpoint is that algorithm rollovers are very, very tricky in 
production, so you would want to make it less likely that you'll have to 
roll over to a new algorithm, and start out with the most robust 
algorithm that is implemented in a reasonable number of clients, *and* 
is supported by the registrars and registry.  EDUCAUSE is both the 
registrar and registry for EDU and they support the following algorithms:

3:DSA/SHA1
5:RSA/SHA-1
6:DSA-NSEC3-SHA1
7:RSASHA1-NSEC3-SHA1
8:RSA/SHA-256
10:RSA/SHA-512
12:GOST R 34.10-2001

GOST is currently supported by fewer implementations, but algorithms 8 
and 10 are supported by recent versions of BIND and unbound.

Further clouding the issue is that older versions of these DNS servers 
may not support the algorithm and will treat your zone as insecure (but 
not bogus, i.e. validation failure).  In my case, I am actually okay 
with only new clients being able to validate my zone as I put it into 
production: It means fewer clients to break if there are any glitches as 
we roll into production.  That's probably hair-splitting, though.

Anyway, based on the logic above, I chose algorithm 10, but I suspect 
there are plenty of alternative ways to look at it.

michael