RE: Standardize RSA/SHA256 ?

["Hallam-Baker, Phillip" <[e-mail]>]

I suspect that what Russ actually said was that Working Groups should plan to transition from SHA-1 because it is unacceptably weak. 

In the security area the minimum key length for RSA that applications must support has been 2048 bits for some time.

DNSSEC is the only application where a transition from RSA1024 to RSA2048 creates real operational difficulties.
 

I don't think that weak crypto is a show stopper for deployment of DNSSEC, it will be a decade or more before breaking a 56 bit key will be the weakest link in any of the crypto systems in use.

But when developers are being told to update their algorithms it seems to me that you want to make sure that the number of transitions is minimized rather than the extent of each transition.

The task of adding a crypto algorithm to existing code is probably the most trivial coding change you can imagine. But you still have a full QA cycle and a full interop cycle and those are never easy or simple.


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ólafur 
> Guðmundsson /DNSEXT co-chair
> Sent: Friday, May 12, 2006 10:54 AM
> To: Jelte Jansen; [e-mail]
> Subject: Re: Standardize RSA/SHA256 ?
> 
> At 04:56 12/05/2006, Jelte Jansen wrote:
> > >
> > >> For the above reasons, I think that we have time to consider the 
> > >> correct course of action. There is no need to rush into more 
> > >> algorithms which require more code on nameservers and resolvers.
> > >
> > > Yes, or at least, we need to document a more compelling 
> reason to do 
> > > RSA-SHA-265.
> > >
> >
> >So why is this an issue for RSA/SHA256, and not for 
> >draft-ietf-dnsext-ds-sha256-05.txt, which also makes SHA256 
> mandatory?
> 
> <Chair-hat=on>
> The issues here are slightly different.
> 
> DS digest is the SAME for the lifetime of the DS record.
> Digest inside a RRSIG is going to be different each time the 
> signature is regenerated for that set, thanks to the 
> different signature lifespan timers.
> Thus in the case of DS an attacker has much longer to be able 
> to generate a DNSKEY that has a matching DS digest to an existing one.
> 
> The WG was advised by our Security Area Advisor (Russ 
> Housley) that any use of SHA-1 without HMAC wrapper should be 
> retired. As DS was the most vulnerable the chairs got that 
> effort stared on the spot and RFC4509 should be published any day now.
> 
> <Chair-hat=off>
> A mitigating fact that RRSIG is not as vulnerable as plain 
> text, against the known SHA1 attacks, is the structured data 
> format of an RRset.
> Having said that if attack on RRSIG digest, or other 
> structured formats, is valuable enough some smart people will 
> figure out a way to design such an attack.
> 
> Following up on Hilarie and Rip's messages:
> One part of the security analysis should be how long 
> signature lifetime can be for the different digest algorithms 
> used as a function of time.
> This is similar to what is available for lengths of public keys.
> 
>          Olafur 
> 
> 
> --
> to unsubscribe send a message to 
> [e-mail] with the word 'unsubscribe' 
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 
> 

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