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

From: Jelte Jansen <[email-masked]>
Date: Thu, 18 Jun 2009 11:42:02 +0200

Hi,

I am the editor of http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-rsasha256-14

which has seen its share of trouble, but is finally nearing WGLC.

This draft defines the use of RSA/SHA256 and RSA/SHA512 with DNSSEC.

We were about to call it, when Alfred Hoenes mentioned to me that the IESG will 
probably raise an issue about the use of SHA512 in this draft.

For practical reasons, it does not specify keys larger than 4096 bits to use 
with RSA/SHA-512, while normally, much larger keysizes are chosen for use with 
the bigger digest values. So he suspects that this definition should be removed 
or reduced to SHA/384.

So my question is, do you as the security directorate think the same, and should 
I change this before going into last call?

Thanks,

Jelte Jansen

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jun 2009 07:06:14 -0700

At Thu, 18 Jun 2009 11:42:02 +0200,
> I change this before going into last call?

Well, I would ask why you're specifying either 384 or 512.

SHA-256 would have to be weakened *very* badly before it would
be necessary to move up, at which point what makes you think
that SHA-384/512 will be strong? 

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Jun 2009 11:14:54 -0400

> that SHA-384/512 will be strong? 

The point of this is just to get things done.  It has taken a
remarkably long time to get this SHA-2 draft through the WG -- the
current revision is -14, and when we started everyone (including the
incredibly patient Jelte) thought this was a quick housekeeping
problem.  The draft specifies 256, but while we were at it we thought
512 might be a good idea too, so that it'd be done in case we needed
it later.

Does that change your response?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Jun 2009 09:35:44 -0700

>Does that change your response?

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".

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%.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Jun 2009 13:02:49 -0400

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
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Jun 2009 11:00:42 -0700

At 1:02 PM -0400 6/18/09, Andrew Sullivan wrote:
>that something you would oppose? 

No.

>Is it something against which you
>advise?

Yes.

Eric's question is still germane. What attack do you see on SHA256 that makes the cost of SHA512 worth it?

>implementing for the following reasons [insert secdir reasons here].

"We're defining RSA/SHA-512 but we really don't think that there is any good use for it at this time. If we feel that there is a good reason for it, we will publish another RFC that explains why."

Again, by the mere act of defining the code point, you will cause a huge waste of resources. Developers will code it prematurely. Naive sysadmins will sign their zones with it. The signatures will traverse the Internet.

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 18 Jun 2009 20:44:44 +0200

> Again, by the mere act of defining the code point, you will cause a huge waste of resources. Developers will code it prematurely. Naive sysadmins will sign their zones with it. The signatures will…

Just for a bit of recent history; originally the draft only defined 256. There
were some people who wanted to do all SHA2 algorithms 'while we're at it' (the
reasoning being, even if there is no known attack on 256 right now, it wouldn't
hurt to have stronger algorithms in there to be ready for the future, not so
much for the IETF overhead, but for deployment times). Because we didn't want to
waste code points, we decided on selecting two. Conforming key sizes weren't
taken into account here.

Since most implementations use crypto libraries that either don't support SHA2
at all or support both 256 and 512, it doesn't seem like a waste of resources
from an implementation point of view (of course I could be wrong here).

I don't want to define something and essentially tell people not to use it until
another RFC comes along; the definition could also go in there then. If it's
defined I expect people to use it (in fact, partly due to some overeager
developers and some misconceptions about the time this all would take, there
happens to be one implementation in the wild that actually uses them right now,
which isn't a problem, but will be if the code point that was chosen gets
assigned to another algorithm).

So, if it's up to me, SHA512 is going to be either in there 'fully' (albeit with
keys that are way to small) or not at all.

Jelte