Subject: Review of draft-ietf-dnsext-ds-sha256-01.txt

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 10:03:22 -0800

I published the latest copy of the -ds draft a week ago or so (the
announcement was sent to this list as well).  I'm now interested if
there are any outstanding issues with the draft.  In particular,
please review sections 3 and 4 which are the sections that changed the
most based on feedback from the working group.

In order for this document to go forward, it needs do be reviewed by
at least 5 people (per recent discussion at the last IETF and on the
list).  The WG chairs would like acks at least from 5 people that have
read the draft.
-- 
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: "Scott Rose" <[email-masked]>
Date: Tue, 6 Dec 2005 13:31:36 -0500

One minor typo:

Section 3, second para:

"This behavior SHOULD by the default."

/by/be/

I've read this version, and I don't have any objections about going forward
with this version.  Sorry about not stating earlier.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Wes Hardaker
> Sent: Tuesday, December 06, 2005 1:03 PM
> To: [email-masked]
> Subject: Review of draft-ietf-dnsext-ds-sha256-01.txt
>
>
>

---

From: Mike StJohns <[email-masked]>
Date: Tue, 06 Dec 2005 13:40:46 -0500

Hi Wes -

I've reviewed the document and I'm fine with it going forward as is 
now especially given the security issues with SHA1.

BUT (and feel free to send me off to the corner if this was discussed 
prior), wouldn't it have made sense to either do the other two SHA 
standards (SHA384 and SHA512) at the same time  in the same document, 
or either as different algorithm types or having the subtypes encoded 
in the digest field?

Two nits
  - [SHA256] should probably just be [SHA] as it covers 1, 256, 384 and 512.
  - Should SHA1 be deprecated with the publication of this document?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Dec 2005 13:46:30 -0500

Quoting http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ds-sha256-01.txt:

#1.  Introduction
#
#   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
#   zones to distribute a cryptographic digest of a child's Key Signing
#   Key (KSK) DNSKEY RR.  This DS RR is signed using the parent zone's
#   private half of it's DNSKEY and the signature is published in a RRSIG
#   record.

The DS RRset is signed by at least one of the parent zone's private 
zone data signing keys for each algorithm in use by the parent.  Each 
signature is published in an RRSIG resource record, owned by the same 
domain as the DS RRset and with a type covered of DS.

(Just cleaning up the "private half" colloquialism.  Personally, I 
hate trying to sign with half of a key. ;))

#2.  Implementing the SHA-256 algorithm for DS record support
#
#   This document specifies that the digest type code [XXX: To be
#   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] for

Good job - that request is in the IANA considerations section.

#   use within DS records.  The results of the digest algorithm MUST NOT
#   be truncated and the entire 32 byte digest result is to be published
#   in the DS record.
#

...

#2.2.  DS Record with SHA-256 Wire Format
#
#   The resulting packet format for the resulting DS record will be [XXX:
#   IANA assignment should replace the 2 below]:

I would not use "packet format" but rather something like 
"on-the-wire" (okay, laugh about my use of an anachronism after 
telling you I didn't like a colloquialism).  The reason I'm saying 
this is that the "packet" would also have the DNS header, yadda, 
yadda, yadda.  I just don't want anyone to think that this is a new 
DNS packet format.

#
#                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
#       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
#      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#      |           Key Tag             |  Algorithm    | DigestType=2  |
#      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#      /                                                               /
#      /            Digest  (length for SHA-256 is 32 bytes)           /
#      /                                                               /
#      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
#
#2.3.  Example DS Record Using SHA-256
#
#   The following is an example DSKEY and matching DS record.  This

s/DSKEY/DNSKEY/

...

#
#3.  Implementation Requirements
#
#   Implementations MUST support the use of the SHA-256 algorithm in DS
#   RRs.

This is always a sticky point.  It's up to an implementation to decide if it
will support RFC wxyz.

E.g., if I were to be writing a test plan for code, I really need to 
know what it means for code to accurately implement an RFC.  Whether 
the RFC is pertinent is part of an operations "profile" of a standard.

I know that this is a continuing rat-hole discussion in the IETF so I 
don't expect a resolution, but I just want to note that the above 
MUST is one that won't translate will to a test plan.

#   Validator implementations MUST be able to prefer DS records
#   containing SHA-256 digests over those containing SHA-1 digests.  This
#   behavior SHOULD by the default.  Validator implementations MAY

s/by/be/

#   provide configuration settings that allow network operators to
#   specify preference policy when validating multiple DS records
#   containing different digest types.

Unlike the earlier comment (of substance), these "operational" 
requirements makes sense in developing a test plan.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Dec 2005 14:34:02 -0500

> list).  The WG chairs would like acks at least from 5 people that have

I have read this draft, and I'm in favour of it going forward.

One nit I noted (that I haven't seen noted by anyone else yet), in
section 1:

private half of it's DNSKEY and the signature is published in a RRSIG

s/it's/its

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 06 Dec 2005 14:35:42 -0500

At 13:40 06/12/2005, Mike StJohns wrote:

>BUT (and feel free to send me off to the corner if this was 
>discussed prior), wouldn't it have made sense to either do the other 
>two SHA standards (SHA384 and SHA512) at the same time  in the same 
>document, or either as different algorithm types or having the 
>subtypes encoded in the digest field?
>
>Two nits

Mike,

This proposal is made based on guidance from our Security AD, Russ Housley.
Specify SHA256 now and revisit the issue once NIST has issued guidance
on use of SHA-xxx or defined a new standard digest algorithm.
That effort is expected to take about 4 years.

Any guidance from WG members saying they prefer stronger digest
than SHA256, speak up now.

As for deprecating SHA1 right now this is something the editor
is looking for guidance on what the document should say.

         Olafur

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 11:41:21 -0800

>>>>> On Tue, 06 Dec 2005 14:35:42 -0500, [email-masked] (Olafur Gudmundsson) said:

Olafur> As for deprecating SHA1 right now this is something the editor
Olafur> is looking for guidance on what the document should say.

Specifically, there was a discussion surrounding this a while back and
I don't think consensus was reached about whether it should be
deprecated by this document now.  If anything, I think it was leaning
toward it being beyond scope of this document.

-- 
Wes Hardaker
Sparta, Inc.

---

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

>>>>> On Tue, 6 Dec 2005 14:34:02 -0500, Andrew Sullivan <[email-masked]> said:

Andrew> One nit I noted (that I haven't seen noted by anyone else yet), in
Andrew> section 1:

Andrew> private half of it's DNSKEY and the signature is published in a RRSIG

Andrew> s/it's/its

Thanks.  Fixed.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Dec 2005 14:47:13 -0500

>is looking for guidance on what the document should say.

I'd say - lay out the problem with SHA-1 and let 
operators decide if they still want to code bases 
that implement it.  Don't make operational 
"decisions" in a protocol document.

Let's say RFC 10234 defines some approach using 
SHA-1.  RFC 10321 defines the same approach 
saying SHA-256 is safer, warning that SHA-1 is a 
bad idea.

I expect to read on the box my software come in 
to say "compliant with RFC 10234", "compliant 
with RFC 10234 and RFC 10321", "compliant with 
RFC 10321" or "doesn't know anything about SHA." 
That's how I see the RFCs being useful when 
documenting these issues.

Is SHA-1 better than no understandable DS 
records?  (That's the question an operator of a 
resolver needs to ask themself.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 11:48:35 -0800

>>>>> On Tue, 6 Dec 2005 13:46:30 -0500, Edward Lewis <[email-masked]> said:

Ed, thanks for the review...

Edward> The DS RRset is signed by at least one of the parent zone's private 
Edward> zone data signing keys for each algorithm in use by the parent.  Each 
Edward> signature is published in an RRSIG resource record, owned by the same 
Edward> domain as the DS RRset and with a type covered of DS.

So changed.

Edward> #   The resulting packet format for the resulting DS record
Edward> #   will be [XXX: IANA assignment should replace the 2 below]:

Edward> I would not use "packet format" but rather something like 
Edward> "on-the-wire"

Ok.

Edward> #   The following is an example DSKEY and matching DS record.  This

Edward> s/DSKEY/DNSKEY/

gack!

Edward> #   Implementations MUST support the use of the SHA-256 algorithm in DS
Edward> #   RRs.

Edward> This is always a sticky point.  It's up to an implementation
Edward> to decide if it will support RFC wxyz.

I'm not sure what your complaint is here.  Are you saying that it
shouldn't be included or that it should be changed to "Implementations
*that support this specification* MUST ...".

Edward> #   behavior SHOULD by the default.  Validator implementations MAY

Edward> s/by/be/

Thanks (it was actually pointed privately just after publication so
was already locally fixed).

-- 
Wes Hardaker
Sparta, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Dec 2005 15:23:38 -0500

> resolver needs to ask themself.)

That was exactly my worry when I read the previous draft, and I think
this one has enough wiggle room in it to allow the operator to make
the right choice (yet still suggests really strongly that SHA-1 is on
the whole probably better to leave behind).

A

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 13:23:50 -0800

>>>>> On Tue, 6 Dec 2005 15:23:38 -0500, Andrew Sullivan <[email-masked]> said:

>> resolver needs to ask themself.)

Andrew> That was exactly my worry when I read the previous draft, and
Andrew> I think this one has enough wiggle room in it to allow the
Andrew> operator to make the right choice (yet still suggests really
Andrew> strongly that SHA-1 is on the whole probably better to leave
Andrew> behind).

Which was precisely the goal of the current text: make sure operators
can select a secure solution but not mandate that they do so.
Capability is required, forced policy is not.

-- 
Wes Hardaker
Sparta, Inc.

---

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]

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2005 15:00:01 -0800

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

Mark> For what it is worth, in implementing this draft, I found the
Mark> word "prefer" to be very poorly defined.  So much so the code
Mark> needed to be commented to make the intent clear.

How about changing:

   Validator implementations MUST be able to prefer DS records
   containing SHA-256 digests over those containing SHA-1 digests.

to:

   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> At this stage I have no intention of implementing the MAY.

Such is the beauty or ugliness of a MAY depending on your
prospective.

-- 
Wes Hardaker
Sparta, Inc.

---

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

>    SHA-1 digests when a DS RR record exists with a SHA-256 digest and

	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.

---

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

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.  Whether to publish both digest types
   together and for how long is a policy decision that extends beyond
   the scope of this document.

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 6 Dec 2005 18:00:31 -0800 (PST)

>   SHA-1 digests when a DS RR record exists with a SHA-256 digest and

Is this glass-half-full<=>glass-half-empty kind of changes?

I really don't see a difference between these two paragraphs as far
as how implimentation would work...

Also is "MUST be able to" intentional (i.e. instead of just "MUST")?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Dec 2005 21:14:49 -0500

>*that support this specification* MUST ...".

Yeah, that's accurate and testable statement.

---

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

>>>>> On Tue, 6 Dec 2005 18:00:31 -0800 (PST), "william(at)elan.net" <[email-masked]> said:

>> SHA-1 digests when a DS RR record exists with a SHA-256 digest and

william> Is this glass-half-full<=>glass-half-empty kind of changes?

Yes.  It's almost entirely wording nits that people have been talking
about, not about the concepts underneath.

william> I really don't see a difference between these two paragraphs as far
william> as how implimentation would work...

There isn't any.  Mark was stating that the wording wasn't clear in
his mind.  It obviously was in yours if you read it the same way both
times.  :-)

william> Also is "MUST be able to" intentional (i.e. instead of just "MUST")?

Yes.  Because it doesn't mandate policy, it only mandates that it must
be possible to ignore SHA-1 in the presence of SHA-256 but allows for
implementations to accept operator configuration that requires other policy.

-- 
Wes Hardaker
Sparta, Inc.

---

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:

>> SHA-1 digests when a DS RR record exists with a SHA-256 digest and

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.

---

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

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

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

Mark> I'd still prefer the following change

Mark> s/algorithm/algorithm and preferably for every DNSKEY for which a DS is being generated/
	
Ok, but that's actually sort of stating the same thing again.  Can't
we simplify things and just use your last wording without mentioning
algorithms?

  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.

-- 
Wes Hardaker
Sparta, Inc.

---

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

>   how long is a policy decision that extends beyond the scope of this

	I'm fine with this wording.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Dec 2005 09:33:14 +0000

> 	SHA-1 digests if DS RRs with SHA-256 digests are present in the

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

---

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

>   vulnerable to injection attacks if SHA-1 is really broken].

	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: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Dec 2005 07:25:54 -0500

>   records.  This should be done for every DNSKEY for which a DS records

I like this wording.  It gives useful operational guidance without
setting policy.

A

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Dec 2005 08:34:40 -0500

>	go from all DS/SHA1 to all DS/SHA256 without breaking the

I don't think it's right to make the phase out of SHA1 to stated 
goal.  The goal is to define SHA256 as an alternative and document 
why it is better than SHA1 and why an operator (of DNS) ought to 
prefer to use SHA256 (given that SHA1 is already in play).

As a consumer of DNS code, I want code that has as much functionality 
as possible, other things being equal.  E.g., if you released BIND 
9.12.2 with SHA1 in it and the only change for 9.12.3 was to remove 
it - I wouldn't bother to upgrade.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 07 Dec 2005 16:38:44 +0000

--On 07 December 2005 08:34 -0500 Edward Lewis <[email-masked]> wrote:

> I don't think it's right to make the phase out of SHA1 to stated goal.
> The goal is to define SHA256 as an alternative and document why it is
> better than SHA1 and why an operator (of DNS) ought to prefer to use
> SHA256 (given that SHA1 is already in play).

I guess my point is that provided validators continue accepting SHA1,
authoritative servers using SHA256 are still vulnerable to attack, by
spoofing SHA1 records if SHA-1 is broken. IE the operator will be helped
not be using SHA-256, but by the validator not accepting SHA-1. I
appreciate saying that validators MUST NOT / SHOULD NOT / "ought to think
about not" accepting SHA-1 may be too far a step to take, but it seems to
me that the point is not what happens on the authoritative server end, but
the validator end (imagine what would happen if validators accepted DS
records without any digest - and compare that to a totally broken SHA-1).

Alex

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Dec 2005 12:18:01 -0500

>not be using SHA-256, but by the validator not accepting SHA-1. I

(problem - "be" should be "by?")

>records without any digest - and compare that to a totally broken SHA-1).

One basic tenet of DNSSEC - it's about the resolvers, not the servers.

Servers can only make data available to provide "proof" of goodness, 
it's up to the validators to make the right call.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

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:

>> how long is a policy decision that extends beyond the scope of this

Mark> I'm fine with this wording.

Changed.  Thanks (to both you and Andrew)

-- 
Wes Hardaker
Sparta, Inc.

---

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

>>>>> On Wed, 07 Dec 2005 16:38:44 +0000, Alex Bligh <[email-masked]> said:

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.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 08 Dec 2005 13:37:16 +0000

> (problem - "be" should be "by?")

Yes

Alex

---

From: Alex Bligh <[email-masked]>
Date: Thu, 08 Dec 2005 13:39:11 +0000

Wes,

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

Alex

---

From: Chris Thompson <[email-masked]>
Date: Thu, 8 Dec 2005 13:54:49 +0000 (GMT)

> wrong about that, then clearly you are right in the rest of your

How would the MoM sign it? Surely the two DS records are part of the same
RRset, and so signed as a single entity.

-- 
Chris Thompson
Email: [email-masked]

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 8 Dec 2005 08:56:31 -0500

> [mailto:[email-masked]]On Behalf Of Alex Bligh
> Sent: Thursday, December 08, 2005 8:39 AM
> To: Wes Hardaker
> Cc: Edward Lewis; Mark Andrews; [email-masked]; Alex Bligh
> Subject: Re: DS Algorithm selection and SHA1 deprecation
>
>
> Wes,
>

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

---

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

> 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