Subject: Re: DS Algorithm selection and SHA1 deprecation

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 20:30:19 -0800

>>>>> On Wed, 07 Dec 2005 10:25:41 +1100, Mark Andrews <[email-masked]> said:

>> Validator implementations MUST be able to ignore DS RRs containing
>> SHA-1 digests when a DS RR record exists with a SHA-256 digest and
>> covers the same name.

Mark> Validator implementations MUST, by default, ignore DS RRs containing
Mark> SHA-1 digests if DS RRs with SHA-256 digests are present in the
Mark> DS RRset.

I'm fine with that wording but it does change the default requirement
to a MUST from a SHOULD (you've combined two previous requirements (1
MUST and 1 SHOULD) into a single sentence).

I actually think it should be a MUST but my feeling before was that
not everyone would likely agree.  If there are no objections to your
wording, however, I'll use that.

-- 
Wes Hardaker
Sparta, Inc.

--
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 09:33:14 +0000

--On 07 December 2005 10:25 +1100 Mark Andrews <[email-masked]> wrote:

> 	Validator implementations MUST, by default, ignore DS RRs containing
> 	SHA-1 digests if DS RRs with SHA-256 digests are present in the
> 	DS RRset.

I may be missing the point but I thin this argument is beside the
point.

The reason for preferring (in what ever sense - and it's the sense of
"prefer" you seem to be arguing about) SHA-256 is in case SHA-1 gets broken
(for some value of broken). If that occurs, a useful attack mode would
presumably not only involve generating bogus RRsets with SHA-1 digests, but
also ensuring no SHA-256 digests are present.

Therefore, IF it is a concern that SHA-1 is "too easy to break", THEN it
should be an option for the validator to ignore SHA-1 whether or not there
is an SHA-256 digest present or not. As ignoring SHA-1 digests when no
other digests are present is going to render the zone insecure, the
corollary of this would seem to be that you then have to deprecate USING
SHA-1 to sign the DS RRs in the first place (noting that some validators
may not treat DS RRs signed only with SHA-1 as secure, as they may ignore
SHA-1 signed DS RRs).

So it seems to me the two logical options are to say
* SHA-1 MUST NOT be used as a digest for DS RRs. Validators MAY ignore
  DS RRs with SHA-1 digests (whether or not SHA-256 digests are present
  in the DS RRset); [leaves the option open to validators of accepting
  them anyway for back compatibility or whatever] ; OR
* SHA-1 SHOULD NOT be used as a digest for DS RRs. Validators MUST NOT
  ignore DS RRs with SHA-1 digests if there are no DS RRs with SHA-256
  digests present in the DS RRset. Validators MAY ignore DS RRs with
  SHA-1 digests if DS RRs with SHA-256 digests are present in the
  DS RRSet. [This means that even those using only SHA-256 to sign are
  vulnerable to injection attacks if SHA-1 is really broken].

Alex