Subject: Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05

From: Alfred Hönes <[email-masked]>
Date: Tue, 27 Mar 2012 16:02:32 +0200 (MESZ)

A have a few more, mostly editorial comments on
          draft-ietf-dnsext-dnssec-algo-signal-05
(trying to avoid duplicates of items already mentioned this week
in review comments on the list):

1)  General Terminology  (mostly in Section 1), and some nits

* Sect. 1, 2nd para:

"DS" should be spelled out "Delegation Signer", not "Delegated Signer"
-- cf. RFC 3034, sect. 2, "Definition of DNSSEC Terms").
Also, a comma should be placed in front of "like" in that para.

* Sect. 1, 3rd para:

The draft should not say "EDNS attribute" in one place, always more
precisely "EDNS option" (see snippet below).

* Sect. 1, 3rd para, and Sect. 8, 2nd line:

The hashes used in DNSSEC are cryptographic functions/algorithms as
well. Using "cryptographic algorithm" in some places as a substitute
for "[cryptographic|digital] signature algorithm" seems confusing.
This should be fixed.

Additionally, for enhanced clarity, I suggest to shuffle the words
a bit and improve the language in the 3rd para of Section 1:

OLD:
   This draft sets out to specify a way for validating end-system
   resolvers to tell a server which cryptographic and/or hash algorithms
   they support in a DNS query.  This is done using the EDNS attribute
   values in the OPT meta-RR [RFC2671].

NEW:
   This draft sets out to specify a way for validating end-system
   resolvers to tell a server in a DNS query which digital signature
   and/or hash algorithms they support.  This is done using the new
   EDNS options specified below in Section 2 for use in the OPT meta-RR
   [RFC2671].

2)  "EDNS" vs. "EDNS0"

The EDNS framework is designed to allow expansion while maintaining
backward compatibility, and one method to achieve this is based on
the versioning rules from RFC 2671[bis].  Therefore, we should better
avoid referring specifically to "EDNS0" or "EDNS(0)" when mentioning
facts that are expected to remain strictly unchanged in future EDNS
versions (however unlikely their occurrence may seem now).

In particular, I suggest to  s/EDNS0/EDNS/  twice in the 1st para
of Sect. 2, once in the 2nd para of Sect. 6, and once in Sect. 8.

3)  error in example ??

In the last para of Section 2, the byte counts given apparently
do not match the other information.  I suspect the figures have
inadvertently not been updated upon the change in the EDNS option
structure the draft has undergone.
IMHO, "16-24 octets" should read "24-34 octets":

OLD:

   However, in practical terms including all three options are likely to
|  take up 16-24 octets (average of 6-10 digital signature algorithms,
           ^^^^^
   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
   EDNS option codes and option lengths in a reasonable potential future
   example.

NEW:
                              v                             vv
|  However, in practical terms, including all three options is likely to
|  take up 24-34 octets (average of 6-10 digital signature algorithms,
           ^^^^^
   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
   EDNS option codes and option lengths in a reasonable potential future
   example.

(Note that "including" acts as the subject in this sentence, so the
verb "are" needs to be in singular form, "is"; I also added a comma.)

The lower bound (22) corresponds to the lower counts mentioned,
and the upper bound to the upper counts each:

-  fixed overhead for DAU:    4 octets  \
-  code list for DAU:      6-10 octets  / 10-16 octets
-  fixed overhead for DHU:    4 octets  \
-  code list for DHU:       3-5 octets  /  7-9  octets
-  fixed overhead for N3U:    4 octets  \
-  code list for N3U:       3-5 octets  /  7-9  octets
++++++++++++++++++++++++++++++++++++++++++++++++++++++
total:                                    24-34 octets

4)  typo in Sect. 3, 2nd para

OLD:

   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
|  signature codes for cover a potentially wide range of algorithms and
                   ^^^
   are likely not useful to a server.  [...]

NEW:

   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
|  signature codes both cover a potentially wide range of algorithms and
                   ^^^^
   are likely not useful to a server.  [...]

5)  Section structure

The current sections 3.2 and 3.3 are, from a logical/semantical
perspective, subordinate to the current Section 3.1 in the same
way as Sections 3.4.1 and 3.4.2 are subordinate to Section 3.4.
I suggest to restructure s3.1-3.3 and renumber the rest of s3:

    3.2    -->  3.1.1
    3.3    -->  3.1.2
    3.4    -->  3.2
    3.4.1  -->  3.2.1
    3.4.2  -->  3.2.2

6)  Reference update

The revised EDNS0 specification is ahead in the IESG, therefore I
suggest to update the citations to RFC 2671 toward the 'bis' document.

Best regards,
  Alfred.

---

From: Scott Rose <[email-masked]>
Date: Tue, 27 Mar 2012 12:44:15 -0400

Thanks - we will fix those comments in the next revision.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Mar 2012 09:55:12 +0200

Okay, I admit that this is a derailment attempt.

This document started out as an effort to negotiate what information 
was sent in a DNS message exchange.  The document now describes a 
means for a querier to signal something about its capability.

Sitting around the venue and gabbing, what if we expand on this?  Why 
limit the capability advertisement to just DNSSEC algorithms.  An 
idea that was floated was to represent the RFCs the querier complies 
with (ohh, that "c" word).  Further expanding on this, conformance 
with a general (i.e., not-an-RFC) document could be done via a 
reference in some new IANA document registry.

Compliance - this would require a means to, in a binary way, define 
compliance with an RFC.  That would take some ground breaking work.

These comments aren't meant to stop the current document processing 
bureaucracy from proceeding but offered as food for thought.  It it 
foreseeable that in 10-15 years we will have lots of things change in 
the DNS.  We know that we lack any version management capability (the 
RFC that defined SHA256 for DS hashes mentions this).  Although it 
will be an eon before we have one, we have to start somewhere.  And 
maybe the current document, such as it is, is the first step.  But in 
talking to people here this week, we could expand the idea.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Miek Gieben <[email-masked]>
Date: Thu, 29 Mar 2012 10:43:13 +0200

[ Quoting <[email-masked]> in "Re: [dnsext] WGLC on draft-ietf-dns..." ]
> talking to people here this week, we could expand the idea.

I, for one, like this. Another IANA registry is one step too far I guess, but
re-using RFC numbers like this seems like an elegant solution.

Regards,
Miek Gieben

---

From: Steve Crocker <[email-masked]>
Date: Thu, 29 Mar 2012 09:55:15 +0100

Miek and Ed,

I'm all in favor of longer term of supporting smooth transitions in the future.  We're paying a huge price with IPv6 for not having done so with addresses, and we are and will continue to have similar problems in other areas.  That said, two comments:

1. I think it's worth moving the present document forward so we can measure the uptake of new algorithms in DNSSEC.  I think the need for algorithm transition is coming sooner than many expect.

2. The specific suggestion of referencing RFCs instead of IANA registry tables is intriguing.  I can see advantages, but I can also see possible problems.  I think the proposed scheme needs a bit of discussion and a design note before moving this forward.

Thanks,

Steve

On Mar 29, 2012, at 9:43 AM, Miek Gieben wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext