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

From: Rob Austein <[email-masked]>
Date: Wed, 29 Jul 2009 14:55:01 +0200

[Continuation of Stockholm WG session, cut off due to lack of time]

My concern with the proposal to sign the root just with SHA-2 is that
it will be years before enough of the installed base has SHA-2-capable
DNSSEC in production.  Even ignoring vendors with long development
cycles, mainstream operators don't upgrade quickly.   We're talking
years here, not months.

I think the suggestion that we start with SHA-1 then roll to SHA-2
makes a fair amount of sense.  If algorithm roll at the root really is
that scary, we should not wait until an emergency to try it.

--
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: Patrik Fältström <[email-masked]>
Date: Wed, 29 Jul 2009 15:07:56 +0200

> that scary, we should not wait until an emergency to try it.

FWIW: This makes sense to me.

What we do need is, for pure interoperability reasons, _one_ algorithm  
that is "the algorithm that is in use", and then a mechanism for  
rollover algorithms when needed.

I would argue strongly against mechanisms that enable what would be a  
terrible tragedy of the commons, which would be simultaneously use of  
unlimited number of algorithms.

    paf

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 29 Jul 2009 13:24:02 +0000

Is there a possibility to sign with BOTH? SHA-1 and SHA-256?

Ondrej.

-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 29 Jul 2009 10:32:03 -0300

> that scary, we should not wait until an emergency to try it.

I'm with Rob. Besides the advantages of testing the roll I would
really not like to depend on a not completely specified and deployed
algorithm for initial deployment.

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 29 Jul 2009 10:33:53 -0300

> Is there a possibility to sign with BOTH? SHA-1 and SHA-256?

If the roots don't fear the TCP traffic.

---

From: Jim Reid <[email-masked]>
Date: Wed, 29 Jul 2009 14:48:06 +0100

> Is there a possibility to sign with BOTH? SHA-1 and SHA-256?

What should the validator do if the SHA-1 signature turns out to be  
invalid but the SHA-256 one was OK? Or vice versa? Would/should there  
be a priority order/preference for validators to pick from when  
choosing between multiple RRSIGs which each have different hash  
algorithms? [Evil thought: perhaps the hash algorithm identifier  
should be a field in the RRSIG rather than the DNSKEY.....] I tend to  
agree with Patrik's suggestion that there should be One True Hash  
algorithm and a mechanism for replacing that when necessary. Hopefully  
there will be plenty of notice before a new hash algorithm would need  
to be introduced, implemented and deployed. I'm not sure if that would  
be a wise assumption however.
--
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: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 06:46:18 -0700

> that scary, we should not wait until an emergency to try it.

	I STRONGLY disagree.  Crypto only gets weaker, never stronger, and it  
can get very SUDDENLY weaker.  The cracks are REALLY showing in SHA-1.

	Resolvers need an update anyway in order to handle a signed root, if  
only the key itself.  Thus I believe it is critical to start with SHA-2.

	Signing BOTH ways doesn't solve the problem, either:  you then become  
vulnerable to downgrade attacks and similar problems.

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 29 Jul 2009 15:57:29 +0200

> cycles, mainstream operators don't upgrade quickly.   We're talking

On the other hand, the installed base of validating resolvers at this
point in time is not yet forgotten by those that installed them. And
everybody just upgraded BIND anyway. (not to a SHA-256 compatible
release, but that is only marginally relevant; it is the practice that
counts.)

> that scary, we should not wait until an emergency to try it.

This is IMHO a more valid argument; but the notion of "they are not done
yet" as was mentioned in the meeting is a dire threat; probably as much
of a delay to adoption as would "lack of SHA-256 capable resolvers"
would be.

SHA-256 for first root key is a good start. A planned rollover after 2
years or so would address the need to do rollover in a controlled way.

The only thing we'd lose with rollover 256>256 would be the algorithm roll.
But I firmly believe that getting people to roll is the hard part. Once
you get "must roll key" into peoples to-do list, the fact that the key
algorithm changes as well is just a minor detail.

-- 
Måns Nilsson

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 29 Jul 2009 15:58:39 +0200

> If the roots don't fear the TCP traffic.

Any resolver doing DNSSEC also does EDNS0. 

-- 
Måns Nilsson

---

From: Florian Weimer <[email-masked]>
Date: Wed, 29 Jul 2009 14:04:35 +0000

* Nicholas Weaver:

> 	Resolvers need an update anyway in order to handle a signed
> root, if  only the key itself.  Thus I believe it is critical to start
> with SHA-2.

SHA-2 support implies NSEC3 support, so this is certainly not a simple
key installation or cryptographic algorithm update for most operators.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 29 Jul 2009 16:05:33 +0200

Jim Reid wrote:
> invalid but the SHA-256 one was OK? Or vice versa? Would/should there be
> a priority order/preference for validators to pick from when choosing
> between multiple RRSIGs which each have different hash algorithms? [Evil

i tried to get something like that in an earlier version of the sha2 draft, but
it got voted out; currently if one or more of the signatures seems correct, the
rrset is marked as ok, according to 4034.

> implemented and deployed. I'm not sure if that would be a wise
> assumption however.

if anyone knows another implementation of the draft (preferably a non-openssl
one), please let me know :)

Jelte

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 07:09:36 -0700

On Jul 29, 2009, at 6:48 AM, Jim Reid wrote:

> invalid but the SHA-256 one was OK? Or vice versa? Would/should  
> there be a priority order/preference for validators to pick from  
> when choosing between multiple RRSIGs which each have different hash  
> should be a field in the RRSIG rather than the DNSKEY.....] I tend  
> to agree with Patrik's suggestion that there should be One True Hash  
> algorithm and a mechanism for replacing that when necessary.  
> Hopefully there will be plenty of notice before a new hash algorithm  
> would need to be introduced, implemented and deployed. I'm not sure  
> if that would be a wise assumption however.

Remember, also, the attitude of "yeah, its cracks are showing but its  
not broken yet from our viewpoint, its just collision attacks" had  
root cert vendors continuing to use MD5:

http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt

That didn't work out very well...

So to ease deployment on those unwilling or unable to update their  
codebase to NSEC3/SHA-256, the solution is to put a potential time- 
bomb into the root signature?

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 29 Jul 2009 10:14:19 -0400

> rollover algorithms when needed.
I would agree with this, but different groups have opinions about what
should be "the" algorithm in use.  That will hamper DNSSEC deployment in
some areas.  If that can be worked out to one agreed upon algorithm, I'd be
very happy. ;-)  

Scott

> unlimited number of algorithms.

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 29 Jul 2009 11:20:11 -0300

> Any resolver doing DNSSEC also does EDNS0. 

Sing a popular zone with 2 KSKs + 2 spare KSKs + 2 ZSKs (6 keys + 4
sigs to the keyset and 2 sigs for the other rrsets) and get back to us
with the traffic results.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jul 2009 00:31:08 +1000

> key installation or cryptographic algorithm update for most operators.

It is for those with NSEC3 support.  :-)

Seriously if you are DNSSEC player you will have or get NSEC3 support
RSN.  Too many high level zones use NSEC3 for developers to avoid it.

> --=20
> Kriegsstra=DFe 100              tel: +49-721-96201-1
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jul 2009 00:34:19 +1000

In message <[email-masked]>, Jim Reid writes:
> On 29 Jul 2009, at 14:24, Ond=C5=99ej Sur=C3=BD wrote:
> 
> What should the validator do if the SHA-1 signature turns out to be =20
> invalid but the SHA-256 one was OK?

	You accept the answer if you support both.  That is what
	the DNSSEC RFC's say to do.

	Mark

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2009 10:45:37 -0400 (EDT)

On Wed, 29 Jul 2009, Nicholas Weaver wrote:

> Remember, also, the attitude of "yeah, its cracks are showing but its not 
> broken yet from our viewpoint, its just collision attacks" had root cert 
> vendors continuing to use MD5:
>
> So to ease deployment on those unwilling or unable to update their codebase 
> to NSEC3/SHA-256, the solution is to put a potential time-bomb into the root 
> signature?

Note that the usage is quite different. Certs tend to be trusted until their
signature expiry time, due to lack of CRL deployments. That makes pulling the plug
on a compromised algorithm very hard.

However, with DNSSEC, we have no requirement to sign "for the future". We can
rollover the key whenever cracking sha-1 has become uncomfortably close to
reality, while at the same time alternatives have become available, and nameservers
have been sufficiently deployed with the new algorithm.

And it is not clear SHA-2 would stand that much longer after SHA-1 falls either,
so I'm not sure what the exact gain is with deploying SHA-2.

What happened to "walk, not run" ?

Paul

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Jul 2009 10:50:58 -0400

At 14:48 +0100 7/29/09, Jim Reid wrote:

>What should the validator do if the SHA-1 signature turns out to be invalid
>but the SHA-256 one was OK? Or vice versa?

The plan in the development of DNSSEC was - if there's one validation 
"chain" that works, then the data is good.  "One that is good" is in 
the eyes of the validator.

(Chorus:)

Adding security to a functioning system make the underlying system 
more brittle. The goal is to limit the increase in the brittleness. 
DNS is a loose system, this is what allows it to scale.  For DNSSEC 
not to screw DNS up, DNSSEC can't be too tight - it has to be 
just-tight-enough.

>Would/should there be a priority order/preference for validators to pick
>from when choosing between multiple RRSIGs which each have different hash
>algorithms?

That's up to local policy.  I'd encourage my competitors to have a 
policy that sets such preferences; to paraphrase a quip from a past 
chair of this group.

Security systems with lots of parameters reminds me of a Johnny Cash lyric:

Can be found here: 
http://www.azlyrics.com/lyrics/johnnycash/onepieceatatime.html

#               Now, up to now my plan went all right
#            'Til we tried to put it all together one night
#   And that's when we noticed that something was definitely wrong.
#
#                     The transmission was a '53
#                And the motor turned out to be a '73
#   And when we tried to put in the bolts all the holes were gone.

(The signer was a '07 and the openssl was a '09 ... same effect.)
The story goes well though:

#              So we drilled it out so that it would fit
#         And with a little bit of help with an A-daptor kit

We just need a good "A-daptor."

(I'm in a musical mood today - last night "The Music of Abba" [a.k.a. 
"Faux Abba"] played at Wolf Trap Park near WashingtonDC/US.  I might 
not be at the IETF in Stockholm, but Swedish culture is paying me a 
visit anyway.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 07:55:23 -0700

On Jul 29, 2009, at 7:34 AM, Mark Andrews wrote:

>> =20

This leaves open to downgrade attacks etc.  Two signatures, with one  
broken, general equals one broken signature.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 08:00:32 -0700

On Jul 29, 2009, at 7:45 AM, Paul Wouters wrote:

>> Remember, also, the attitude of "yeah, its cracks are showing but  
>> its not broken yet from our viewpoint, its just collision attacks"  
>> had root cert vendors continuing to use MD5:
>>

But there is a huge difference between "key rollover" and "algorithm  
rollover", especially if the better algorithm was specifically NOT  
used the first time because of some unspecified deployment fears.

> so I'm not sure what the exact gain is with deploying SHA-2.

More bits in the same family tend to paper over a LOT of sins.   
SHA-256 gives a fair bit more safety margin than SHA-1s 160bit.

> What happened to "walk, not run" ?

What happened to avoid known-problems?

SHA-1 is a known problem.  SHA-256 is better.  Not better ENOUGH (I'd  
like to see a formal commitment to shift to the Advanced Hash function  
winner after it gets NSA approval for Top Secret communication), but  
better.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Jul 2009 17:55:40 +0200

In your previous mail you wrote:

=> support != use so I don't understand your concern (or it is about
the NSEC3 code complexity and .gov already chose for you :-).

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Jul 2009 18:02:54 +0200

if anyone knows another implementation of the draft (preferably a
   non-openssl one), please let me know :)
   
=> is your concern about OpenSSL for SHA-2 or for RSA? In the second
case I have a dnspython hack using OpenSSL for hash but the builtin
big intergers for RSA, so I can adapt it to SHA-2. Just send a message
to me to my other/company address...

Regards

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 29 Jul 2009 12:10:20 -0400

>winner after it gets NSA approval for Top Secret communication), but

References please.

<no-hat>
There is a big difference IMHO using SHA-1 in DNSSEC signatures that 
are valid for
a "short" time compared to the "long" time that CERT's live.
If you look at the tread starting at
http://psg.com/lists/namedroppers/namedroppers.2009/msg00785.html

In particular:
http://psg.com/lists/namedroppers/namedroppers.2009/msg00848.html

         Olafur

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 29 Jul 2009 18:25:15 +0200

On 29 jul 2009, at 16.29, Basil Dolmatov wrote:

>> What we do need is, for pure interoperability reasons, _one_  
>> algorithm that is "the algorithm that is in use", and then a  
>> mechanism for rollover algorithms when needed.
>>
>> I would argue strongly against mechanisms that enable what would be  
>> a terrible tragedy of the commons, which would be simultaneously  
>> use of unlimited number of algorithms.
> So you will effectively restrict a significant part of the world  
> Internet from usage of this technology.

That is not what I am saying. I am saying the problem you refer to  
should be worked on and resolved, instead of patching around it, as  
patches always are patches.

    Patrik

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2009 12:26:28 -0400 (EDT)

> What happened to avoid known-problems?

To me, the problem to avoid is using algorithms that have not seen a wide deployment.

> SHA-1 is a known problem.  SHA-256 is better.  Not better ENOUGH (I'd like to 
> see a formal commitment to shift to the Advanced Hash function winner after 
> it gets NSA approval for Top Secret communication), but better.

If you see moving to the Advanced Hash function winner soon, then what is the problem
of starting with sha1 and moving to sha2 once its seen a few more adoptions in
commonly deployed nameserver software?

There seems to be two reasons to do SHA-256:

- SHA1 is too weak (not true for the next two years IMHO, and if that
   estimate is wrong, you can decrease the rollover interval to counteract)
- Algorithm rollover is scary (As you said, it will happen sooner rather
   then later anyway)

Reasons to start with SHA-1:

- Give SHA-256 some more time to get deployed and tested
- Give vendors more time to test nameserver software with SHA-256
- Don't add the "you must upgrade software" roadblock to people who
   just want to use a deployed signed root.

Paul

---

From: Basil Dolmatov <[email-masked]>
Date: Wed, 29 Jul 2009 18:29:31 +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. ]

Maybe that makes sense, I should evaluate that.

dol@

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 09:59:02 -0700

>> winner after it gets NSA approval for Top Secret communication), but

Even as old as 2005 it was known SHA-1 had problems:
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2009 14:36:28 -0400 (EDT)

> http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

 	2^106 calculations: much less than the 2^160 calculations for brute force.

You are going to break that within a month? Even if you do get a collision, that's
far from being able to create your own malicious spoofed record that appears
correctly signed.

> http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1

 	To that end, a collision search for SHA-1 using the distributed
 	computing platform BOINC began August 8, 2007, organized by the
 	Graz University of Technology. The effort was abandoned May 12,
 	2009 due to lack of progress.

If you really think SHA1 is that weak, you can do various things:

- More frequent KSK/ZSK rollovers
- Use NSEC3 and change the seed regularly
- Buy all PS3's from Sony before they get to the NSA

So even if significant progress is made towards breaking SHA1, there are
methods to "walk, not run" to SHA-256 or something else.

Roy's argument about zone size is a good one though. We might not want to
commit to that if we don't have to yet, though a lot of broken setups
will break with any DNSSEC deployment, and those who still do not support
ENDS0 or TCP will realisticly only upgrade after they break, so whatever
we do to mitigate that will just postpone the inevitable.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 11:47:34 -0700

On Jul 29, 2009, at 11:36 AM, Paul Wouters wrote:

Read further:

> Cameron McDonald, Philip Hawkes and Josef Pieprzyk presented a hash  
> collision attack with complexity 2^52 at the Rump session of  
> Eurocrypt 2009[28].

That is, to my mind, BROKEN.  2^52 for collision generation (it should  
be 2^80) is a big big deal.

These are the symptoms seen before MD5 fell completely.

And SHA1 has already been revoked by NIST for government use:

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
http://csrc.nist.gov/groups/ST/toolkit/documents/shs/NISTHashComments-final.pdf

> Federal agencies should stop using SHA-1 for digital signatures,  
> digital time stamping and other applications that require collision  
> resistance as soon as practical, and must use the SHA-2 family of  
> hash functions for these applications after 2010. After 2010,  
> Federal agencies may use SHA-1 only for the following applications:  
> hash-based message authentication codes (HMACs); key derivation  
> functions (KDFs); and random number generators (RNGs). Regardless of  
> use, NIST encourages application and protocol designers to use the  
> SHA-2 family of hash functions for all new applications and protocols.

SHA1 is dead, that you guys are even CONSIDERING SHA-1 for the root  
signature for DNSSEC is frankly, silly.  SHA1 has been considered dead  
since 2006 in the eyes of NIST.

---

From: bert hubert <[email-masked]>
Date: Wed, 29 Jul 2009 21:01:44 +0200

> http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1

Let's not get our panties in a bunch too much. Even if you could
collide a hash, you'd have a very hard time getting that to mean
anything.

And even if you could craft an RRSET that hashed identically, you'd
need to do so before the RRSIG expires, and then get that answer
injected - which is highly non-trivial anyhow.

Also be aware that the liberty to hijack, let's say, an A record is
constrained. What you could do is add 10 evil A-records, and
manipulate a bunch of trailing A-records in order to get the hash to
match. I'm not entirely sure of the state of the art wrt MD5
collisions, but my impression is that you need to fiddle with a (for
DNS terms) non-trivial amount of garbage in order to get things to
work.

This might translate to 10 'evil' A records and 10 garbage A records,
for example - but even in that case you can't fiddle all the bits
indiscriminately - the names of the records need to continue to match
for example. Plus everything needs to remain in canonical order, and
presumably you'd want to corrupt the first record in the RRSET etc.

I'm not weighing in on the full discussion as I have too little
experience with DNSSEC deployments, but I did want to point out that
because people have been able to collide a certificate does not mean
they can collide an RRSET in canonical order.

     Bert

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Jul 2009 22:31:05 +0200

At 2:55 PM +0200 7/29/09, Rob Austein wrote:
>DNSSEC in production.

This surprised me. Which DNSSEC resolvers have SHA-1 but not SHA-2 today?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Jul 2009 22:42:00 +0200

>http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1

Please stop the FUD about SHA-1. Those articles are about probable problems with SHA1's collision resistance. That is not applicable for the root signing TLDs. Even if such a collision can be done (it still has not been shown in practice, as compared to MD5), the scenario where it could be of damage to DNSSEC is both obscure and trivial to detect.

Please stop the FUD about SHA-2. There have been no known attacks either on the collision resistance (which is easier, but not important in this use), nor on the preimage resistance.

Please stop the FUD about SHA-3 or whatever it will be called. The NSA has never said (nor even hinted) that, after it is chosen that it will be a candidate for any level of classified use.

I cannot speak for Olafur, but I would guess that when he asked for references, he meant ones that were relevant to this WG and supported your statements, not just random URLs about somewhat related topics.

--Paul Hoffman, Director
--VPN Consortium

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 29 Jul 2009 16:53:02 -0400 (EDT)

> that scary, we should not wait until an emergency to try it.

I concur with Rob, primarily for the "let's force an algorithm 
rollover early on" reason.  I'd very much like for us to prove to the 
world that algorithm rollover just works.  And I'm happy to have that 
rollover scheduled from the very beginning, just so there's no debate 
later about when to do it.  Let's do it in twelve months.

Similarly, I hope that we will see several early KSK rollovers, 
perhaps once a year for the first 3-5 years of having a signed root, 
just to give resolver operators an opportunity to develop and test 
their KSK rollover procedures.

I'm not particularly worried about market penetration of the SHA256 
code.  I'm more interested in making sure the (hopefully rarely used) 
operational procedures get exercised.

-- Sam

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 29 Jul 2009 14:13:27 -0700

On Jul 29, 2009, at 1:42 PM, Paul Hoffman wrote:
> I cannot speak for Olafur, but I would guess that when he asked for  
> references, he meant ones that were relevant to this WG and  
> supported your statements, not just random URLs about somewhat  
> related topics.

http://csrc.nist.gov/groups/ST/hash/statement.html

Including

> The first of these is to transition rapidly to the stronger “SHA-2”  
> family of hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) for  
> digital signature applications. The SHA-2 hash functions are in the  
> same general family of hash functions as SHA-1. They could  
> potentially be attacked with similar techniques, but they are much  
> stronger than SHA-1. Practical SHA-2 attacks are unlikely in the  
> next decade; and might never be found, except through decades of  
> exponential growth of available computing power. The SHA-2 hash  
> functions are well along in the commercial system deployment process  
> and are available in many newer systems and applications, but are  
> not yet available in the majority of deployed systems. The primary  
> constraint on the current use of the SHA-2 hash functions for  
> signatures is interoperability; many relying party systems do not  
> yet implement them, and may not do so for several more years. NIST  
> encourages a rapid adoption of the SHA-2 hash functions for digital  
> signatures, and, in any event, Federal agencies must stop relying on  
> digital signatures that are generated using SHA-1 by the end of 2010.

When NIST says "Don't do it, it may be hazardous", back in 2006! thats  
usually a good indication that an algorithm should not be used.  SHA-1  
is revoked for federal use effective Dec 31, 2010.

The only reasons given for using SHA-1 over SHA-2 is that I can tell:

There exist some resolvers:
a:  Properly support DNSSEC using SHA-1
b:  Do not support SHA-2
c:  Can not or will not be upgrade to support SHA-2
     when being updated with the root's public key

How many such resolvers are there where all three conditions are true?

Worse, there is an additional condition proposed:
d:  Will be able to quickly transition to SHA-2 if a crisis
     actually occurs

This discussion I find, frankly, bizarre.  SHA-1 should be dead for  
new deployments.  DNSSEC may be a long time in coming, but the key  
gating feature, a signed root, is a new thing.  Even discussing the  
deliberate use of a dead and scheduled-to-be-revoked hash algorithm  
seems frankly silly.

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 29 Jul 2009 17:12:13 -0400 (EDT)

On Wed, 29 Jul 2009, Jim Reid wrote:

> invalid but the SHA-256 one was OK? Or vice versa?

According to 4035, so long as there is "a" good chain, the result is 
Secure.  It's very reasonable for a validator to have an option to 
disable algorithms (e.g. if one is discovered to be weak), in which 
case validators with different settings might get different validation 
results.

> Would/should there be a priority order/preference for validators to 
> pick from when choosing between multiple RRSIGs which each have 
> different hash algorithms?

We have not told validators to do that.  A validator could ignore 4035 
and implement such a function.  If so, it might prefer to do so on a 
whole-zone basis rather than a per-RRSIG-RRset basis.  But that's not 
behavior this WG has endorsed, AFAIK.

> [Evil thought: perhaps the hash algorithm identifier should be a 
> field in the RRSIG rather than the DNSKEY.....]

Quit trying to twiddle bits in DNSSEC.  It's Done.  Finally.

(To the point: doing that might circumvent the protection against 
downgrade attacks that we wrote into this protocol some years ago. 
You need to signal the minimum set of cipher suites in use, including 
the hash algorithms, at the zone cut.  Picking-and-choosing on a 
per-RRset basis is a recipe for attacks.)

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Wed, 29 Jul 2009 21:17:39 +0000

> Date: Wed, 29 Jul 2009 16:53:02 -0400 (EDT)
> From: Samuel Weiler <[email-masked]>
> 
> I concur with Rob, primarily for the "let's force an algorithm rollover
> early on" reason.

+1.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 29 Jul 2009 14:38:26 -0700

On Wed, Jul 29, 2009 at 1:53 PM, Samuel Weiler<[email-masked]> wrote:
> Similarly, I hope that we will see several early KSK rollovers, perhaps once
> a year for the first 3-5 years of having a signed root, just to give
> resolver operators an opportunity to develop and test their KSK rollover
> procedures.

If the goal is to give them operational practice, wouldn't it make
sense to instead roll keys once or twice a week during a test period
lasting a few months or something?  Or better, to setup some dummy
keys/servers that continue to cycle once a week indefinitely so a
company starting out a few years from now will be able to still test
that key rollover works fine for them.

Once a year doesn't seem much better than once every N years for the
purpose of letting people test their software/configurations/etc.  I
fear it'll end up like NTP's leap second support: there's protocol
support and the code's there, but there was still a surprising number
of problem reports on the technical mailing lists / blogs that I was
reading when the last one occurred.

In the NTP leap second case, computers are out of sync by about a
second.  In the DNS case, host name resolution breaks.

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 29 Jul 2009 17:57:42 -0400 (EDT)

This is straying away from the originally asked question about 
algorithms (and algorithm rollover) to key rollover.

On Wed, 29 Jul 2009, Matthew Dempsky wrote:

> lasting a few months or something?

I see your point, but no.  Organizations are going to turn on 
validation slowly (by some metric).  Each needs to get practice with 
rollover, not just the early adopters who turn it on during the test 
period.

> Or better, to setup some dummy keys/servers that continue to cycle 
> once a week indefinitely so a company starting out a few years from 
> now will be able to still test that key rollover works fine for 
> them.

That's a useful utility, but not one that addresses my concern, which 
is make sure we have the ability, both technically and politically, to 
do an emergency rollover in the future.

A test server setup assumes they want to test and are awake and paying 
attention.  Part of the point of the semi-slow rollovers of real-world 
keys is to allow time for the person who set up the validating 
resolver to move on to other things (maybe even a different 
organization) and make sure the new operator is still paying 
attention.

> second.  In the DNS case, host name resolution breaks.

Which is perhaps more incentive to fix it.  :-)

Yes, the breakage might be painful, but better to experience it now 
and prove to the world that we can cope so we can resist when someone 
trys to talk us out of an emergency rollover in ten years.

-- Sam

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 30 Jul 2009 01:26:26 +0200

> This surprised me. Which DNSSEC resolvers have SHA-1 but not SHA-2 today?

None of the DNSSEC validators support RSA/SHA-2 at the moment. One had
it, but kind of by accident, and it has been pulled back in recent
updates. There simply is no offically allocated algorithm number yet, so
official support is impossible.

Also, there are quite a bit of operating systems where the most public
crypto lib, openssl, has no support for SHA-2 yet. It's been implemented
in openssl for ages, but for so-called 'stable' branches ages are not
enough. But maybe now that it's at a 1 version they are updated real
soonish now.

OTOH, since we're upgrading our resolvers to do DNSSEC now anyway, we
might as well upgrade them to support SHA-2 while we're at it.

Jelte

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Jul 2009 19:35:41 -0700

Nic and all,

  Nic, your right of course.  And SHA-2 itself is already coming under
pressure/getting weaker.  Yet some transition method from those
using SHA-1 now to SHA-2 is really necessary.  A conundrum
we have here indeed.

  I'm likely the oddball here in that for me SHA-2 is already too
weak for my taste.  For that matter 256bit is too weak, IMO.
But I am sure that is not widely a shared opinion.

> vulnerable to downgrade attacks and similar problems.

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Jul 2009 19:40:09 -0700

Scott and all

  I'd be very happy too if it's stronge enough and a transition period
and process is excepted.  A difficult task to accomplish in so broad
a consideration though.  But doable if cooperation is avaliable.

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Jul 2009 19:59:33 -0700

Nic and all,

  SHA-1 should not in all instances have been revoked by the
USG.  None the less it has been broken some time ago now and
for practical highly sensitive purposes should not be used or
excepted.  Yet for other uses not as sensitive to or by the USG
I see no reason it cannot still be used and accepted, with a
proviso that such has an expiration date of same use.

Regards,

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Jul 2009 07:58:24 +0200

>official support is impossible.

Got it.

Then, no, it is inappropriate to sign any zone, much less the root, with RSA/SHA2 for the foreseeable future. Before the root is signed with RSA/SHA2, a lot of testing will need to be done to determine the level of support for the algorithm in resolvers.

This is truly sad. I hummed (possibly too loudly) for signing with RSA/SHA2. Having said that, there are no known threats against signing the root with RSA/SHA1. The operational hurt of the algorithm rollover will be a black eye for this community, one that could have hopefully been avoided.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 30 Jul 2009 08:09:20 +0200

>http://csrc.nist.gov/groups/ST/hash/statement.html

Um, following a complaint about random URLs with another one is not necessarily a good way to enlighten the WG.

>When NIST says "Don't do it, it may be hazardous", back in 2006! thats usually a good indication that an algorithm should not be used.

...but only if you read what they actually said. Sorry to be so repetitive, but there are different uses for hashes, and each has its own security threats. If you lump all of them together, you will get the wrong result.

>  SHA-1 is revoked for federal use effective Dec 31, 2010.

No, it is not. It is prohibited *for some uses*, including signing when the signer does not control the material being signed.

>d:  Will be able to quickly transition to SHA-2 if a crisis

Please carefully define what would cause a crisis for DNSSEC with respect to SHA-1. Using that careful definition, look at the rest of the world's use of SHA-1 in places where a similar attack could happen. Then explain why anyone would give a rodent's patootie about our problems relative to, say, the entire banking sector, protection of physical resources, and so on.

>This discussion I find, frankly, bizarre. 

Ah! A point of agreement!

--Paul Hoffman, Director
--VPN Consortium

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 30 Jul 2009 08:55:11 +0200

On 29 jul 2009, at 14:55, Rob Austein wrote:

>  Even ignoring vendors with long development

I would think that folk who configure DNSSEC to use the roots trust- 
anchor would be doing that with up-to-date software and as such the  
deployment of DNSSEC is a forcing function towards a new upgrade cycle  
and SHA256 piggybacks along. I could be easily convinced that that is  
a bad (somewhat naive) assumption.

--Olaf

---

From: Doug Otis <[email-masked]>
Date: Thu, 30 Jul 2009 09:10:16 +0200

>> Worse, there is an additional condition proposed: d:  Will be able
>> to quickly transition to SHA-2 if a crisis actually occurs
>
> Please carefully define what would cause a crisis for DNSSEC with
> respect to SHA-1. Using that careful definition, look at the rest of
> the world's use of SHA-1 in places where a similar attack could
> happen. Then explain why anyone would give a rodent's patootie about
> our problems relative to, say, the entire banking sector, protection
> of physical resources, and so on.

A possible crisis could be caused by a requirement for significantly
more resources needed to support the algorithm roll-over, especially
early in the DNSSEC learning curve.  This might be mitigated by a new
signature selection parameter.

-Doug

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2009 10:16:36 +0200

> signature selection parameter.

I think we must assume that an algorithm roll will be necessary at  
some point in the future, regardless of whether it is RSA/SHA-1 to RSA/ 
SHA-2. So choosing RSA/SHA-2 at day zero does not help us avoid work  
on algorithm rollover, but it does perhaps defer that work (on the  
grounds that RSA/SHA-2 is likely to be safe for longer than RSA/SHA-1).

The mechanics of an algorithm rollover will surely require some  
consideration and testing, from an operational perspective if not a  
protocol perspective.

However, the NTIA has expressed publicly a goal of having the root  
signed by the end of 2009. Even if that date slips, I think the  
detailed planning that the community surely expects to be done for  
that work will require the protocol to be used to be specified far  
earlier than that, before anybody can have clear knowledge about the  
timelines for RSA/SHA-2 codepoint assignment, implementation or  
deployment.

Is it reasonable to think that an RSA/SHA-2 code-point could be  
assigned and that code could be released, tested and deployed early  
enough to allow planning for its use by the end of 2009?

If the answer is no, then perhaps we have an answer.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Jul 2009 05:30:50 -0400

On Thu, Jul 30, 2009 at 10:16:36AM +0200, Joe Abley wrote:
> Is it reasonable to think that an RSA/SHA-2 code-point could be assigned 
> and that code could be released, tested and deployed early enough to 
> allow planning for its use by the end of 2009?

This is a good question (indeed, the right one, I think). 

I will be sending the SHA-2 draft to the IESG soon (I need to complete
the writeup.  I'm working on that today, as it happens).  Then it
needs to go to IETF last call.  It is hard to predict whether we will
get exploration of various ratholes about whether DNSSEC is a good
idea, whether SHA-256 is ok, &c. during that last call.  We've also
been warned that the specification of SHA-512 in there might result in
some heartburn; the editor decided to leave that alone because, on
balance, he felt (and I agreed) that more delay was a bad thing.

So I cannot say whether the code would be released in time for the
planned use date.  But I don't think one should anticipate a code
point actually being assigned for this purpose until at least
September.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Jul 2009 21:05:29 +1000

> This is a good question (indeed, the right one, I think). 

For those validators that are NSEC3 aware already it should be no
more than a afternoon's work to add support.  There are plenty of
sha2 implementations that can be picked up if they don't already have
a sha2 implementation for TSIG.

For validators that arn't NSEC3 aware there is a enourmous amount
of work involved.

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2009 13:09:30 +0200

> point actually being assigned for this purpose until at least

This suggests two options with respect to signing the root, then:

1. Sign with RSA/SHA-1 on current schedule;

2. Defer signing of the root until 2010/2011/2012 (depending on  
implementation and deployment in the validator population) and use RSA/ 
SHA-2.

Are those the two options available to us, in practical terms, or am I  
missing others?

Joe

---

From: John Schnizlein <[email-masked]>
Date: Thu, 30 Jul 2009 14:17:33 +0200

On 2009Jul30, at 1:09 PM, Joe Abley wrote:
> implementation and deployment in the validator population) and use  
> RSA/SHA-2.
>
> Are those the two options available to us, in practical terms, or am  
> I missing others?

Signing with SHA-1 and then with SHA-2 as soon as it has a code point  
would enable cautious validators to do just SHA-2 at their earliest  
convenience.  Having both would be the first part of the rollover  
anyway, wouldn't it?

John

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2009 14:25:16 +0200

On 30-Jul-2009, at 14:17, John Schnizlein wrote:

> Signing with SHA-1 and then with SHA-2 as soon as it has a code  
> point would enable cautious validators to do just SHA-2 at their  
> earliest convenience.  Having both would be the first part of the  
> rollover anyway, wouldn't it?

I think that during a normal KSK rollover we will see a dual-publish  
interval of 30 days, in accordance with 5011. This seems incompatible  
with what you are suggesting.

The inference is that an algorithm rollover would be timed differently  
from a regular, scheduled KSK rollover.

Perhaps that's to be expected, and it's not practical to execute a key  
rollover with an algorithm change in the same schedule as a normal key  
rollover, but I thought I'd call it out anyway.

Joe

---

From: John Schnizlein <[email-masked]>
Date: Thu, 30 Jul 2009 14:58:24 +0200

On 2009Jul30, at 2:25 PM, Joe Abley wrote:
> interval of 30 days, in accordance with 5011. This seems  
> incompatible with what you are suggesting.

I guess I read the 30 days as a minimum based on the following  
excerpt.  Without urgency in removing the key-to-be-replaced,  
exploring both could be leisurely.

2.4.2.  Remove Hold-Down Time

    The remove hold-down time is 30 days.  This parameter is solely a  
key
    management database bookeeping parameter.  Failure to remove
    information about the state of defunct keys from the database will
    not adversely impact the security of this protocol, but may end up
    with a database cluttered with obsolete key information.

>
> The inference is that an algorithm rollover would be timed  
> differently from a regular, scheduled KSK rollover.
>
> Perhaps that's to be expected, and it's not practical to execute a  
> key rollover with an algorithm change in the same schedule as a  
> normal key rollover, but I thought I'd call it out anyway.

I confess not seeing why algorithm rollover (especially for key- 
length) needs to have different timing.  I don't know if we have  
consensus that key-roll for compromise would use 5011, but using an  
execution path that is regularly exercised has a lot in its favor.

John

---

From: Joe Abley <[email-masked]>
Date: Thu, 30 Jul 2009 15:31:19 +0200

On 30-Jul-2009, at 14:58, John Schnizlein wrote:

> length) needs to have different timing.

I think it has been suggested that a key rollover which involves an  
algorithm change might need to last as long as it takes for people to  
get confidence that there is deployed support for the new algorithm,  
before the departing key disappears.

> I don't know if we have consensus that key-roll for compromise would  
> use 5011, but using an execution path that is regularly exercised  
> has a lot in its favor.

I don't think we're talking about emergency key rollover.

Joe

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 30 Jul 2009 15:54:07 +0200

Joe Abley wrote:
>> I confess not seeing why algorithm rollover (especially for
>> key-length) needs to have different timing.
> 

well, if there's no significant support you might as well wait with the start of
the roll until there is (unless you intend to just have both, which could be
seen as a very long roll, then this may be true)

but i think it comes from the idea that algorithm rollovers have to be handled
differently from rollovers with the same algorithm, but i too am not sure that
this would affect the actual timing issues

>> use 5011, but using an execution path that is regularly exercised has
>> a lot in its favor.
> 

if the projected fear about the imminent demise of sha-1 becomes a reality,
maybe we should be.

btw, count me in the camp for 'let's try a roll real soonish'. it will have to
happen at one time in the future

Jelte

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Jul 2009 10:42:24 -0400

> some areas.  If that can be worked out to one agreed upon algorithm, I'd be

I think we all agree that SHA-2 is the best algorithm today, but it is 
not available in the timeframe available.  So, we have to make an 
*ENGINEERING* decision to go with SHA-1 now.

The move to SHA-2 can be announced well in advance (we could make the 
announcement of a date now if we could coordinate with enough of the 
long-devel/deployment cycle vendors/operators.  I'm thinking like 
Dec.31, 2012 or something like that)

(The NIST replacement will be available by then, and maybe we would move 
directly to that, but I doubt it)

This means that we can, as Rob points out, do this as a non-emergency 
key rollover.   I do not believe that SHA-2 signatures are necessarily 
bigger than SHA-1 signatures (it's the number of bits of the RSA key 
that determines the size), but having two signatures for any length of 
time on things like ".com IN NS" may be a concern.  (have most of the 
ccTLDs max'ed out the number of NS returns that fit into 576 bytes?)

---

From: Joe Abley <[email-masked]>
Date: Fri, 31 Jul 2009 17:37:24 -0400

On 31-Jul-2009, at 10:42, Michael Richardson wrote:

> but having two signatures for any length of time on things like  
> ".com IN NS" may be a concern.

Note that delegation NS RRSets in the root zone (and glue A and AAAA  
RRSets) will not be signed. Those sets get signed in the zones which  
are authoritative for them.

Joe

---

From: Jim Reid <[email-masked]>
Date: Fri, 31 Jul 2009 22:59:20 +0100

> are authoritative for them.

True, but it doesn't detract from the point Michael was making about  
the operational impact of bloat in signed replies from busy name  
servers. It'll just be the TLD name servers which have to contend this  
issue instead of the root servers when the TLD's NS RRset is signed.  
I'm not sure if that's a help or hindrance operationally. On the one  
hand, it should mean the root servers would get fewer TCP retries and/ 
or EDNS0 jumbograms than first thought. On the other, that load will  
hit TLD name server infrastructure which in most cases isn't as robust  
as the root servers.

---

From: Joe Abley <[email-masked]>
Date: Fri, 31 Jul 2009 18:04:07 -0400

On 31-Jul-2009, at 17:59, Jim Reid wrote:

>> Note that delegation NS RRSets in the root zone (and glue A and  
>> AAAA RRSets) will not be signed. Those sets get signed in the zones  
>> which are authoritative for them.
>
> True, but it doesn't detract from the point Michael was making

Sure.

---

From: bert hubert <[email-masked]>
Date: Sat, 1 Aug 2009 00:54:25 +0200

On Fri, Jul 31, 2009 at 11:59 PM, Jim Reid<[email-masked]> wrote:
> True, but it doesn't detract from the point Michael was making about the
> operational impact of bloat in signed replies from busy name servers. It'll
> just be the TLD name servers which have to contend this issue instead of the
> root servers when the TLD's NS RRset is signed. I'm not sure if that's a
> help or hindrance operationally. On the one hand, it should mean the root
> servers would get fewer TCP retries and/or EDNS0 jumbograms than first

Much love for introducing me to the word 'jumbogram' :-) The wikipedia
even has a page on it.

But seriously, it would be really great if the .ORG operators could
provide us with more operational details on the ratio of UDP/TCP
queries, TC responses etc.

Because so far we are discussing a lot based on suppositions, and not on data.

    Bert

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 31 Jul 2009 19:22:47 -0400

> *ENGINEERING* decision to go with SHA-1 now.
I agree.  At the beginning of the thread, I was my usual conservative on
security self, thinking "Bite the bullet, deploy the stronger algorithm."

Then, I read that the only pre-release code had been backed out.  Let's
remember the mantra: "rough consensus and RUNNING CODE."

Since there's no running code for SHA-2, deploy SHA-1 now.  It's not
likely to be broken for this threat class anytime in the next year.

After all, we know of threats that such minimal signing will prevent NOW!

> Dec.31, 2012 or something like that)
Oh, I'd be even more aggressive.  Start the phase-in exactly 30 days after
two interoperable implementations become available.  Treat it like an
actual threat.  Push hard, to test the process.

Then, 30 days after that, the old SHA-1 root key will go away.

Aim for 2 interoperable implementations by February 1st.

Aim for starting rollover on March 1st.

Aim for retiring SHA-1 by April 1st.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 31 Jul 2009 19:45:24 -0400

> Aim for retiring SHA-1 by April 1st.

One is tempted to read that suggestion as significant.

A

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