RE: DS Algorithm selection and SHA1 deprecation

["Scott Rose" <scottr@nist.gov>]

> -----Original Message-----
> From: owner-namedroppers@ops.ietf.org
> [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Alex Bligh
> Sent: Thursday, December 08, 2005 8:39 AM
> To: Wes Hardaker
> Cc: Edward Lewis; Mark Andrews; namedroppers@ops.ietf.org; Alex Bligh
> Subject: Re: DS Algorithm selection and SHA1 deprecation
>
>
> Wes,
>
> --On 07 December 2005 11:22 -0800 Wes Hardaker
> <hardaker@tislabs.com> wrote:
>
> > 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.
>
> 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.
>

If the DS RR is removed, the covering RRSIG wouldn't validate (needs the
entire RRset).

The validator would get confused and be unable to continue the validation
chain, but it would be able to know it was under attack.

Scott


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