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

On Wed, 1 Feb 2012, Matthijs Mekking wrote:

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

Perhaps.  I decided not to change anything on this pass.

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

The MUST should stay.  (The MUST must stay?)  You're right about 
administrative boundaries, but things break if these rules aren't 
followed.  They really are a MUST.

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

I understand the reasoning, but I'm not entirely sure what you're 
proposing.  And it does sound like a real change.  And one that may 
not match current code.  I'm not sure this is a great idea.

-- Sam
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext