Re: DS Algorithm selection and SHA1 deprecation

[Mark Andrews <Mark_Andrews@isc.org>]

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

	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.

	You can do this in a number of ways.

	1.  deploy validators which support DS/SHA256, wait serveral
	    years for there to be a critical mass of validators then
	    start generating DS/SHA256 records and stop generating
	    DS/SHA1.

	2.  deploy validators which support DS/SHA256, start generating
	    both DS/SHA256 and DS/SHA1, when there is critical mass stop
	    generating DS/SHA1.

	Now when both exist you can "choose any" or "prefer one over the
	other" which in practice means you need to ignore one when the
	other is present.  Note there is not enough information in a DS
	record to match the DS/SHA1 and the DS/SHA256 for the same key
	w/o generating both hashes hence the requirement to generate
	both for each key.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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