Subject: Re: DS Algorithm selection and SHA1 deprecation

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2005 08:44:51 +1100

For what it is worth, in implementing this draft, I found the
	word "prefer" to be very poorly defined.  So much so the
	code needed to be commented to make the intent clear.
	
	At this stage I have no intention of implementing the MAY.

	Apart from that and the already mentioned typo it was fine.

	Mark

@@ -1678,6 +1678,7 @@
        dns_rdata_rrsig_t sig;
        dst_key_t *dstkey;
        isc_boolean_t supported_algorithm;
+       isc_uint8_t digest_type;
 
        /*
         * Caller must be holding the validator lock.
@@ -1840,6 +1841,25 @@
 
        supported_algorithm = ISC_FALSE;
 
+       /*
+        * If DNS_DSDIGEST_SHA256 is present we are required to prefer
+        * it over DNS_DSDIGEST_SHA1.  This in practice means that we
+        * need to ignore DNS_DSDIGEST_SHA1 if a DNS_DSDIGEST_SHA256
+        * is present.
+        */
+       digest_type = DNS_DSDIGEST_SHA1;
+       for (result = dns_rdataset_first(val->dsset);
+            result == ISC_R_SUCCESS;
+            result = dns_rdataset_next(val->dsset)) {
+               dns_rdata_reset(&dsrdata);
+               dns_rdataset_current(val->dsset, &dsrdata);
+               dns_rdata_tostruct(&dsrdata, &ds, NULL);
+               if (ds.digest_type == DNS_DSDIGEST_SHA256) {
+                       digest_type = DNS_DSDIGEST_SHA256;
+                       break;
+               }
+       }
+

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 20:40:56 -0800

>>>>> On Wed, 07 Dec 2005 12:09:28 +1100, Mark Andrews <[email-masked]> said:

Draft> Because zone administrators can not control the deployment support of
Draft> SHA-256 in deployed validators that may referencing any given zone,
Draft> deployments should consider publishing both SHA-1 and SHA-256 based
Draft> DS records for a while.  Whether to publish both digest types
Draft> together and for how long is a policy decision that extends beyond
Draft> the scope of this document.

Mark> I think this needs to be strengthend.  This currently allows
Mark> you to use SHA-1 for one algorithm and SHA-256 for a different
Mark> algorithm.  This really needs to be made pair-wise.  If you
Mark> choose to publish both then you need to do this for every
Mark> DNSKEY you are generating a DS for.

The rather strong previous consensus was not to dictate operational
requirements at all.  Thus I think what should be added to alleviate
your concerns with different algorithm choices:

  Because zone administrators can not control the deployment support
  of SHA-256 in deployed validators that may referencing any given
  zone, deployments should consider publishing both SHA-1 and SHA-256
  based DS records for a while.  If multiple algorithms are used for a
  given name then both SHA-1 and SHA-256 based DS records should be
  published for every algorithm.  Whether to make use of both digest
  types and for how long is a policy decision that extends beyond the
  scope of this document.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2005 15:59:22 +1100

>   types and for how long is a policy decision that extends beyond the

	I'd still prefer the following change

	s/algorithm/algorithm and preferably for every DNSKEY for which a DS is being generated/
	
	One per algorithm is the minimum required to prevent the
	delegation going unsecure.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Dec 2005 22:43:43 +1100

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

	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

---

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

>>>>> On Wed, 07 Dec 2005 18:50:12 +1100, Mark Andrews <[email-masked]> said:

>> Because zone administrators can not control the deployment support of
>> SHA-256 in deployed validators that may referencing any given zone,
>> deployments should consider publishing both SHA-1 and SHA-256 based DS
>> records.  This should be done for every DNSKEY for which a DS records
>> are being generated.  Whether to make use of both digest types and for
>> how long is a policy decision that extends beyond the scope of this
>> document.

Mark> I'm fine with this wording.

Changed.  Thanks (to both you and Andrew)

-- 
Wes Hardaker
Sparta, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 08 Dec 2005 14:03:21 +0000

--On 08 December 2005 08:56 -0500 Scott Rose <[email-masked]> wrote:

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

Yes Geoff just walked in and explained it. There's one RRSig to cover
*all* the digests. I was thinking "but this could be vulnerable to
the SHA-1 attack too". The point, however, is that if ALL parent
zones up to the root have SHA-256, this vulnerability isn't there either.

So I agree that a validator that accepts and SHA-1 digest does not
degrade the security of a signer who signs with SHA-256 and possibly
other digests, assuming SHA-256 is preferred. Which means I also
agree with the proposed text.

Apologies for the rat-hole.

Alex