Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16

From: Samuel Weiler <[email-masked]>
Date: Wed, 1 Feb 2012 10:11:14 -0500 (EST)

Thanks to all who have reviewed this doc during the WGLC (Mark, 
Wouter, Ed, Mike, Mohan, Warren, and Bill).  I want to assure you that 
your comments are not being ignored -- I plan to respond to most of 
them in bulk at the end of the WGLC.  I'm responding to this one now
since it may require some more discussion.

On Wed, 25 Jan 2012, W.C.A. Wijngaards wrote:

> The section and appendix on CD bits are long.  Not wrong, but long.

I know, and I concur.  The chairs directed the editors to add this 
text, which is the result of a design team meeting reported on this 
list (well, on namedroppers).  I didn't feel strongly enough about it 
to refuse.

Feel free to make a stronger case for leaving some of it (e.g. the 
whole appendix) out.

> Section 6.2 is correct.  But its tone is loose.  It is about lenient
> acceptance of the SEP flag.  Please say that, or say that the proper
> setting of the SEP flag is defined in its RFC.

I'll try to improve this when making the changes at the end of WGLC.

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

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 01 Feb 2012 17:27:27 +0100

I have reviewed and support publication. Here are my comments.

1. Section 5.4. Caution About Local Policy and Multiple RRSIGs

1a. Nit
The second paragraph raises concerns when a resolver adopts a more
restrictive security policy. On the first read, it is not immediately
obvious why there can be unnecessary validation failures. Perhaps a
small explanation is needed, that the restrictive policy is requiring
all signatures to validate?

2. Section 5.11. Mandatory Algorithm Rules

2a. Nit
Typo: pressence -> presence

2b.
The section states that a signed zone MUST include a DNSKEY for each
algorithm present in the zone's DS RRset and expected trust anchors for
the zone. I argue if MUST is too strong, and would vote for SHOULD, for
the reason that the expected trust anchors and DS RRset are being
maintained outside the administrative boundaries of the zone owner.

3. Section 6.4. Erros in RFC 5155

I would like to see some clarifying or guiding text about the
contradiction in this RFC on the Flags field I posted earlier to this list:

Section 8.2 of RFC 5155 states that a validator MUST ignore NSEC3 RRs
with a Flag fields value other than zero or one. But in the IANA
Considerations section, bits 0-6 are available for assignment.

However, assigning a meaning to one of the bits 0-6 would break NSEC3
conformance because that would allow for Flag fields value larger than
one and that conflicts with the rule in Section 8.2 . As a result,
assigning a meaning to one of the bits 0-6 in the NSEC3 Flag fields
would require an update at the resolver side to ignore the bits it does
not implement, regardless of the total outcome value of the Flag fields.
Such a requirement allows for a more flexible approach for future
updates of the NSEC3 Flag fields, with a nice backwards compatibility
property.

Best regards,
  Matthijs

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Feb 2012 10:55:50 -0800

Big:

5.10 is long, scary, and useless for most environments because most environments will have just one trust anchor. Please add the following after the first paragraph of the section:

When DNSSEC was first published, many sites had multiple (and sometimes nested) trust anchors. Now, it is believed that very few do. If a site has a single trust anchor, the information in this entire section can safely be skipped.

Medium:

5.6 (setting the DO bit in replies) suggests resolvers should "be liberal in what they accept". That's a bit vague. Instead, say what you mean "In order to interoperate with implementations that ignore this rule on sending, resolvers need to allow either the DO bit to be set or unset when receiving responses". However, that's still not as honest as I would like. "Because some implementations ignore this rule on sending, the rule for receivers is now that they MUST NOT expect the DO bit to be set as it was sent."

In 5.8, it is unclear what "protect" means. Either clarify what is being protected or use a different word.

Small:

1.1 should start "The clarifications and changes to ..."

--Paul Hoffman