Subject: [DNSOP] Review of draft-ietf-dnsop-attrleaf

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2018 11:17:47 -0400

I've reviewed this document and I think it's in pretty good shape, and is
just about ready to be sent up for publication.  I have some editorial
comments that are mostly minor in nature, as follows:

Section 1.1:

OLD:

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" [RFC1035
<https://tools.ietf.org/html/rfc1035>],
   [RFC2782 <https://tools.ietf.org/html/rfc2782>], [RFC6335
<https://tools.ietf.org/html/rfc6335>], [RFC7553
<https://tools.ietf.org/html/rfc7553>].

NEW (formatting):

   The scoping feature is particularly useful when generalized resource
   record types are used -- notably "TXT", "SRV", and "URI" (see
[RFC1035 <https://tools.ietf.org/html/rfc1035>],
   [RFC2782 <https://tools.ietf.org/html/rfc2782>], [RFC6335
<https://tools.ietf.org/html/rfc6335>], and [RFC7553
<https://tools.ietf.org/html/rfc7553>]).

OLD:

   when they are the underscored name closest to the DNS root; they are
   considered 'global'.  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

NEW (consistent quoting; this is the first of several instances):

   when they are the underscored name closest to the DNS root; they are
   considered "global".  Underscore-based names that are farther down
   the hierarchy are handled within the scope of the global underscore
   name.

Section 1.3:

OLD:

   presentation convention described in Section 3.1
<https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-11#section-3.1>
or [RFC1034 <https://tools.ietf.org/html/rfc1034>] this is

NEW (typo, comma):

   presentation convention described in Section 3.1
<https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-11#section-3.1>
of [RFC1034 <https://tools.ietf.org/html/rfc1034>], this is

Section 2:

COMMENT:

   o  If a public specification calls for use of an underscore-prefixed
      domain node name, the 'global' underscored name -- the underscored
      name that is closest to the DNS root -- MUST be entered into this
      registry.

Use of "MUST" in the RFC2119 sense needs the RFC2119 boilerplate,
which isn't included in the document. This also appears in several
spots in Section 4.

I'm also not sure it applies here; there's no obvious threat to
interoperability if someone does this but doesn't register it.

(More generally, I've frequently been told that MUSTard in IANA
Considerations is a no-no.)

OLD:

   An underscored name define scope of use for specific resource record

NEW:

   An underscored name defines the scope of use for specific resource record

Section 4.1:

OLD:

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character (_) and is the underscored

NEW (include the ASCII value):

   The DNS Global Underscore Scoped Entry Registry is any DNS node name
   that begin with the underscore character ("_", ASCII 0x5F) and is
the underscored

OLD:

   o  The required Reference for an entry MUST have a stable resolution
      to the organization controlling that registry entry

NEW (missing trailing period):

   o  The required Reference for an entry MUST have a stable resolution
      to the organization controlling that registry entry.

COMMENT:

The DNS is case-insensitive so this is a minor point, but would there
be any benefit to specifying that the registry only records the
all-lowercase version of an underscore name?

COMMENT:

The text specifically calls for a stable reference.  Do we have
guidance about what constitutes such a thing?  I believe IANA has its
own guidelines to that end; are they available to the Designated
Expert?

Section 6:

COMMENT:

I have doubts that SECDIR would accept this one-sentence comment.  I
suggest saying something more specific, like:

"This document establishes a registry, and encourages a slight
reorganization of attributes stored in the DNS.  It establishes no new
security issues."

Section 6.1:

COMMENT:

This seems to me to be content that belongs in its own section outside
of Section 6 since it doesn't seem to me to be a security issue, but
it's worth saying.  Maybe give it its own section between what's now
Sections 3 and 4?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Jul 2018 09:21:33 -0700

Folks,

I'm responding to Murray's impressive proofreading details offlist, but 
there are some points he raises that might need wg discussion:

On 7/18/2018 8:17 AM, Murray S. Kucherawy wrote:
> 
> COMMENT:
> 
> The DNS is case-insensitive so this is a minor point, but would there be 
> any benefit to specifying that the registry only records the 

Mumble.  The registry entries, of course, are not DNS entities.  So 
aspects of registry use might care, such as for comparisons.

And since uniqueness is the whole goal, forcing entries to use a single 
case simplifies comparison.  I'm inclined to do as Murray suggests.

> COMMENT:
> 
> The text specifically calls for a stable reference. Do we have guidance 
> about what constitutes such a thing? I believe IANA has its own 
> guidelines to that end; are they available to the Designated Expert?

I'm inclined to let IANA raise this if they see and issue and then let 
them drive the resolution of this point.

> reorganization of attributes stored in the DNS. It establishes no new 

The first clause is redundant and makes sense to have here only either 
if the readers of this section haven't read the rest of the document, or 
if the clause is useful to what follows.  I believe neither applies here.

I don't understand the 'encourages' statement but suspect I don't agree.

That leaves language that is equivalent to the existing language...

> it's worth saying. Maybe give it its own section between what's now 

Well, I agree it's awkward where it is, but gosh.  An entire major 
section?  For such a small and explanatory -- rather than 
specification/normative bit of text? Mumble.

If no one minds, I would rather make it Section 1.4, just after the 
sub-section tht describes the construct.  I think it actually works well 
there.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2018 12:28:05 -0400

> there are some points he raises that might need wg discussion:

Aw shucks.

>> about what constitutes such a thing? I believe IANA has its own guidelines
>> to that end; are they available to the Designated Expert?
>>
>

Yeah, I don't have the right answer either, but I'm concerned that we're
asking the DE to make a decision with guidelines she doesn't have (or
worse, come up with some that are not consistent with what IANA usually
does).

> The first clause is redundant and makes sense to have here only either if
> the readers of this section haven't read the rest of the document, or if
> the clause is useful to what follows.  I believe neither applies here.
>

I imagine myself as a SECDIR reviewer, and believe this would be the first
section I would read for any document to which I'm assigned.  Discovering
there a sentence that basically says "None" would get my back up ("We'll
see about that!").

More generally, I have had success with my proposed tactic in the past, so
I thought I'd suggest it here.

Reading the document, I got the impression that in your research you
discovered some underscore names that don't quite follow the proposed
placement.  If my inference is wrong, then so is that clause.

> Section 6.1:
>>
>> COMMENT:
>>
>> This seems to me to be content that belongs in its own section outside of
>> Section 6 since it doesn't seem to me to be a security issue, but it's
>> worth saying. Maybe give it its own section between what's now Sections 3
>> and 4?
>>
>

That works too.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Jul 2018 09:50:25 -0700

On 7/18/2018 9:28 AM, Murray S. Kucherawy wrote:
> On Wed, Jul 18, 2018 at 12:21 PM, Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Folks,
> 
>     I'm responding to Murray's impressive proofreading details offlist,
>     but there are some points he raises that might need wg discussion:
> 
> 
> Aw shucks.
> 
> 
>         COMMENT:
> 
>         guidance about what constitutes such a thing? I believe IANA has
>         its own guidelines to that end; are they available to the
>         Designated Expert?
> 
> 
>     I'm inclined to let IANA raise this if they see and issue and then
>     let them drive the resolution of this point.
> 
> 
>         I have doubts that SECDIR would accept this one-sentence
>         comment. I suggest saying something more specific, like:
> 
>         reorganization of attributes stored in the DNS. It establishes
>         no new security issues."
> 
> 
>     The first clause is redundant and makes sense to have here only
>     either if the readers of this section haven't read the rest of the
>     document, or if the clause is useful to what follows.  I believe
>     neither applies here.
> 
> 
> I imagine myself as a SECDIR reviewer, and believe this would be the 
> first section I would read for any document to which I'm assigned.  
> Discovering there a sentence that basically says "None" would get my 
> back up ("We'll see about that!").
> 
> More generally, I have had success with my proposed tactic in the past, 
> so I thought I'd suggest it here.

I've gotten decreasingly tolerant of using gambits in a specification 
document, in order to maneuver through the process. I think the document 
should say what it needs to to do its job and not have material that is 
primarily for appeasement those in charge.  Gambits add cruft, and often 
mislead the reader into thinking there is substance when there isn't.

(I think I hit my limit when we appeased an AD for KIM and added the 
requirement for the DKIM signature cover the From: field, thereby aiding 
in community misunderstanding of what DKIM does.)

If the suggested change had any actual substance with respect to 
security issues, that would be quite a different matter.  But it doesn't.

Obviously if the wg would prefer different language, we'll use it...

> placement.  If my inference is wrong, then so is that clause.

sorry, but apparently something is getting in the way of my 
understanding this issue.  Now I'm confused about the 'placement' 
reference.

Anyhow, the only problematic, existing specs, I think, are the SRV and 
URI documents, because they create naming complexities that invite 
problems.  Especially the two-source approach that the URI spec has.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2018 13:04:42 -0400

On Wed, Jul 18, 2018 at 12:50 PM, Dave Crocker <[email-masked]> wrote:

>> Discovering there a sentence that basically says "None" would get my back
>> up ("We'll see about that!").
>>
> requirement for the DKIM signature cover the From: field, thereby aiding in
> community misunderstanding of what DKIM does.)
>
> If the suggested change had any actual substance with respect to security
> issues, that would be quite a different matter.  But it doesn't.
>

It's not a major issue (to me).  Just a suggestion.

> sorry, but apparently something is getting in the way of my understanding
> this issue.  Now I'm confused about the 'placement' reference.
>

I'm willing to accept that I'm inventing a problem here that doesn't
actually exist, and you're advocating more generally for keeping this
section as terse as possible, so let's skip it.

-MSK