Re: DS Algorithm selection and SHA1 deprecation

[Alex Bligh <alex@alex.org.uk>]

--On 07 December 2005 10:25 +1100 Mark Andrews <Mark_Andrews@isc.org> 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

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