Subject: RE: Standardize RSA/SHA256 ?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 May 2006 14:04:19 -0700

> [mailto:[email-masked]] On Behalf Of Ólafur 
> Guðmundsson /DNSEXT co-chair

> At 14:18 08/05/2006, Mike StJohns wrote:
> >Um...
> >
> >OK...  I don't think this is the right question or set of 
> questions to 
> >ask.  Obviously stronger is good but:
> >
> >1) Should we standardize RSA/SHA256?   - Yes
> >2) Should we standardize DSA/SHA256?  - No comment?
> >3) Should we deprecate RSA/SHA1?  Yes, but what does that mean?
> >4) Should RSA/SHA256 be Mandatory to Implement (at both the signing 
> >side and the resolver side)?  Yes.
> >5) Should the root (and/or lower trust anchors) be signed with 
> >RSA/SHA256 in addition to or in replacement of RSA/SHA1? - 
> Well, that 
> >brings in the whole question of algorithm rollover...and "downgrade 
> >attacks"  *sigh*
> >
> >So while I would agree that this might be "A GOOD THING" - I 
> think its 
> >handwaving to just say yes to RSA/SHA256 without dealing 
> with all the 
> >other things.
> 
> Thanks Mike for your list of follow up questions, few comments:
> Q2: is a different question and does not belong here, but 
> this is a related
>          question. As far as I can tell right now no-one has 
> shown any interest
>          in using DSA when deploying DNSSEC. As long as that 
> is the case the
>          question about DSA/SHA256 should be asked at the 
> same time as the
>          kill DSA question is raised.

DSA signatures are as secure as the RSA 2048 signatures but the signature
itself is only 64 bytes as opposed to 256 bytes

Unlike ECC DSA is unencumbered.

I think that it is by far the most interesting technology on offer.

It is true that the cryptographers are worried about SHA1 but a lot more
cryptographers are worried about RSA1024 than the type of attack against
SHA1 that is relevant to DNSSEC.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 May 2006 14:11:50 -0700

> [mailto:[email-masked]] On Behalf Of Wes Hardaker

> >>>>> On Mon, 08 May 2006 11:41:23 -0400, [email-masked] 
> (Olafur Gudmundsson) said:
> 
> Olafur> The alternative to defining RSA/SHA256 now is to wait for 
> Olafur> efforts to standardize new digest algorithms by NIST 
> which will take 4-5 years.
> 
> I believe we should standardize it now rather than wait.  If 
> we believe that a particular algorithm will likely used in 
> the future, and I believe this one will be, then I don't see 
> the point in waiting to define it later if we have the time 
> and energy now.  More importantly, I think it would be 
> detrimental to delay defining it now assuming it will be 
> defined at some point.

I second this, it is far more important to get something that looks like
DNSSEC deployed than that it be secure against every imaginable attack.

History shows that we are considerably better at doing in the field fixes to
broken crypto than deploying crypto infrastructure. Consider that SSL2.0 and
WEP were both proposed after DNSSEC but deployed in strong, fixed form some
time ago.

Waiting for the outcome of the NIST competition is missing the point,
whatever comes out of that process will be functionaly identical to SHA256.

---

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 11 May 2006 22:30:12 -0400

> Without a risk analysis specific to DNSSEC, I cannot support 
> standardization of RSA/SHA256.
> 
> Hilarie

I feel as though I should ask, "What is this 'risk analysis'
of which you speak?" but instead I'll:

1.  State that I think RSA/SHA256 is worth standardizing
    now.  I was perhaps one of those who helped convince the
    author to write the specific document being discussed,
    so I'd doggone better support the idea.
2.  Agree that I think it's worth clearly stating why, so
    that others can review and have their own thoughts
    (now and in the future).
3.  Agree with most of the points in Mike StJohns' recent
    e-mail on this in which he pointed out that it's not
    really a single question "should we standardize this"
    but a whole family of related questions.  I think it's
    probably worthwhile for the WG chairs to respond to that
    mail.
4.  Ask whether a risk analysis specific to some $protocol
    that is in a form which would satisfy the above specific
    objection from Hilarie is readily available so that I
    could use that format as the starting point to write up
    a something. I think I could do one from scratch (perhaps
    poorly) but I'd rather have a better idea of the desired
    endstate.

  --Rip

(And yes, for Olaf/Ólafur, if I care enought to start writing
text on this then that means I should bring the last I-D I
was working on out of hibernation first unless you think it
is OBE.  Please advise.)

--
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/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 11 May 2006 20:07:09 -0700

In other words before deciding to fix the exhaust consider the fact that the clutch is slipping and the big end bearings are about to go.

 -----Original Message-----
From: 	Loomis, Rip [mailto:[email-masked]]
Sent:	Thu May 11 19:36:37 2006
To:	Hilarie Orman; Ólafur Guðmundsson /DNSEXT co-chair
Cc:	[email-masked]
Subject:	RE: Standardize RSA/SHA256 ?

  --Rip

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 17 May 2006 20:39:46 -0700

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.

> From: [email-masked] 
> Sent: Friday, May 12, 2006 10:54 AM
> To: Jelte Jansen; [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.