Subject: Re: one review of the DS thingy by WestWes

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.

--
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: Edward Lewis <[email-masked]>
Date: Tue, 6 Dec 2005 14:47:13 -0500

At 14:35 -0500 12/6/05, Ólafur Guðmundsson /DNSEXT co-chair wrote:

>As for deprecating SHA1 right now this is something the editor
>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

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

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

---

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

---

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.

---

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.

         Olafur

---

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

---

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