Subject: Re: [dnsext] Signing the root with SHA-1 or SHA-2

From: "Roy Arends" <[email-masked]>
Date: Wed, 29 Jul 2009 18:06:47 +0200

Rolling to a new algorithm is no sinecure. It essentially means that both 
algorithms need to be used in parallel for a fair amount of time. There 
will be two events. Event 1 adds RSASHA256 keys and signatures to the 
root. Event 2 removes RSASHA1 keys and signatures from the root. What is 
the exit strategy for RSASHA1 (i.e. when will event 2 happen), without 
evidence of a sginificant cryptanalysis of SHA1? When is it safe to remove 
it, without a significant set of validators (who only support RSASHA1) 
being unable to validate? Is that day when all of the TLDs support 
RSASHA256 only? When will it be safe for TLDs to phase out RSASHA1?

I fear that there will be a significant period where the root has to 
support both algorithms, after event1. That means that the DNSKEY set 
becomes larger. That means that there will be more signatures in a 
response. The DNSKEY set will have a minimum of 4 DNSKEYs. Assuming 2Kbit 
KSKs and 1K ZSKs. That is going to be 6Kbit in key material. During a KSK 
(not algorithm) roll, add 2Kbit key material. This results in 8Kbit key 
material + 6Kbit signature material, which results in 14Kbit, or a 
response size of at least 1792 bytes. (obviously this will be a lot larger 
as this number _just_ shows the crypto)

EDNS0 buffer size doesn't help here. The bulk of the resolvers will fall 
back to tcp, or fail due to dropped fragments if incorrect edns buffer 
sizes are announced.

We can significantly move this problem of large response size further in 
the future if the root is signed with RSASHA2.

There are many more considerations, for and against, I just wanted this to 
be taken into consideration.

Kind Regards,

Roy Arends
Nominet

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jul 2009 11:12:30 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Roy Arends wrote:
> response. The DNSKEY set will have a minimum of 4 DNSKEYs. Assuming 
> 2Kbit KSKs and 1K ZSKs. That is going to be 6Kbit in key material. 
> During a KSK (not algorithm) roll, add 2Kbit key material. This results 
> in 8Kbit key material + 6Kbit signature material, which results in 
> 14Kbit, or a response size of at least 1792 bytes. (obviously this will 
> be a lot larger as this number _just_ shows the crypto)

1792 bytes is too big.
Silly question: once RSASHA256 is available, can we "weaken" the RSASHA1 
key, i.e. reduce it from 2Kbit to 1536, for instance. Does that buy us 
enough room?   (If you want more security, you should validate RSASHA256)

2048*2+1536*2+2*1024 = 9216 bits = 1152 bytes.

Can we avoid rolling both keysets at the same time?
2048 + 1536*2 + 2*1024 = 896 bytes.
2048*2 + 1536*1 + 2*1024 = 960 bytes.

> the future if the root is signed with RSASHA2.

But, that's not the option.  The decision is:
   1) sign with RSASHA1 now
   2) sign with RSASHA256 in 1-2 years.

Only, in 2 years the discussion will just be:
   1) sign with RSASHA256 now.
   2) sign with SHA-3 in 1-2 years.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>