Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2

[Andrew Sullivan <[e-mail]>]

On Thu, Jun 18, 2009 at 09:35:44AM -0700, Paul Hoffman wrote:

> In the security area, we have discovered that if something
> security-related is defined, people will use it even if it is
> stupid. "That's a bigger number, so it will be safer" is a common
> theme, but so is "they would not have specified that algorithm
> unless they wanted everyone to implement it".

This is not a property confined to the security area, but I bet you
know that ;-)  

> Thus, I think Eric's question still stands. Your response in the
> document could be "we define this because of the IETF overhead of
> doing so, not because we want you to use it now", but I suspect that
> will only reduce the number of people who use the signature
> algorithm for absolutely no good reason by less than 50%.

Let me ask the question a different way.  We have now a definition for
512 but with a key size that MUST NOT be larger than 4096 bits.  Is
that something you would oppose?  Is it something against which you
advise?

If the answer to the 1st of those questions is "yes", then it would be
very helpful if we could get a short statement from secdir that we
could take to the WG to say, "We're removing 512 from this document on
the advice of the secdir, and here's their statement."  (We might want
to define 512 later with a larger max key size, but given that we have
at least one working implementation for 256 it'd be nice to get the
existing draft out the door.)

If the answer to the 2d of those questions is "yes" but the answer to
the 1st is "no", then we can put a note in the implementation
considerations to the effect that, while we've defined this for
completeness, implementors might want to think twice about
implementing for the following reasons [insert secdir reasons here].

I appreciate your feedback on this topic -- it's way better to hash
this out now (no pun intended) than later.

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.