Subject: Re: DS Algorithm selection and SHA1 deprecation

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Dec 2005 08:34:40 -0500

At 22:43 +1100 12/7/05, Mark Andrews wrote:

>	What we are trying to do is phase out the use of SHA1.  We are
>	not waiting for SHA1 to be broken.  This is a pre-emptive
>	replacement with SHA256 and we are trying to workout how to
>	go from all DS/SHA1 to all DS/SHA256 without breaking the
>	trust chains.

I don't think it's right to make the phase out of SHA1 to stated 
goal.  The goal is to define SHA256 as an alternative and document 
why it is better than SHA1 and why an operator (of DNS) ought to 
prefer to use SHA256 (given that SHA1 is already in play).

As a consumer of DNS code, I want code that has as much functionality 
as possible, other things being equal.  E.g., if you released BIND 
9.12.2 with SHA1 in it and the only change for 9.12.3 was to remove 
it - I wouldn't bother to upgrade.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

--
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: Alex Bligh <[email-masked]>
Date: Wed, 07 Dec 2005 16:38:44 +0000

--On 07 December 2005 08:34 -0500 Edward Lewis <[email-masked]> wrote:

> I don't think it's right to make the phase out of SHA1 to stated goal.
> The goal is to define SHA256 as an alternative and document why it is
> better than SHA1 and why an operator (of DNS) ought to prefer to use
> SHA256 (given that SHA1 is already in play).

I guess my point is that provided validators continue accepting SHA1,
authoritative servers using SHA256 are still vulnerable to attack, by
spoofing SHA1 records if SHA-1 is broken. IE the operator will be helped
not be using SHA-256, but by the validator not accepting SHA-1. I
appreciate saying that validators MUST NOT / SHOULD NOT / "ought to think
about not" accepting SHA-1 may be too far a step to take, but it seems to
me that the point is not what happens on the authoritative server end, but
the validator end (imagine what would happen if validators accepted DS
records without any digest - and compare that to a totally broken SHA-1).

Alex

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Dec 2005 12:18:01 -0500

>not be using SHA-256, but by the validator not accepting SHA-1. I

(problem - "be" should be "by?")

>records without any digest - and compare that to a totally broken SHA-1).

One basic tenet of DNSSEC - it's about the resolvers, not the servers.

Servers can only make data available to provide "proof" of goodness, 
it's up to the validators to make the right call.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 07 Dec 2005 11:22:10 -0800

>>>>> On Wed, 07 Dec 2005 16:38:44 +0000, Alex Bligh <[email-masked]> said:

Alex> I guess my point is that provided validators continue accepting
Alex> SHA1, authoritative servers using SHA256 are still vulnerable to
Alex> attack, by spoofing SHA1 records if SHA-1 is broken.  IE the
Alex> operator will be helped not be using SHA-256, but by the
Alex> validator not accepting SHA-1.

If a zone operator publishes both SHA-256 and SHA-1 based records then
validators that support SHA-256 will always have a secure path to the
child.  Attackers can not remove the SHA-256 record in the DS RR set
since the RRSIG covering them wouldn't validate.  Thus a validator
would know that data was missing and wouldn't even get the point of
checking the SHA-1 hash.  The only way a SHA-1 DS record can be
attacked (assuming operators do actually prefer SHA-256) is if a
collision is found for an existing DS record and if the DS set only
contains SHA-1 based records.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 08 Dec 2005 13:39:11 +0000

Wes,

> contains SHA-1 based records.

Assuming the malefactor has control over an intervening point in the
network, can he not just prevent the validator from seeing the fact
there is an SHA-256 record there in the first place? (man in the
middle attack - remove the packets and introduce just the
SHA-1 DS record of his choice). This is my assumption - if I'm
wrong about that, then clearly you are right in the rest of your
logic.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Thu, 08 Dec 2005 13:37:16 +0000

> (problem - "be" should be "by?")

Yes

Alex