Subject: [dnsext] [[email-masked]: comments on draft-weiler-dnsext-dnssec-bis-updates 18]

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 May 2012 13:53:18 -0400

Forwarded as suggested.  I think the draft name is misspelled.

A

----- Forwarded message from "Jeremy C. Reed" <[email-masked]> -----

Date: Mon, 7 May 2012 11:21:20 -0500 (CDT)
From: "Jeremy C. Reed" <[email-masked]>
To: [email-masked]
Subject: comments on draft-weiler-dnsext-dnssec-bis-updates 18

The following are my comments on 
draft-weiler-dnsext-dnssec-bis-updates-18.  You may forward my comments 
or reply on list as desired.

4.3.  Check for CNAME

   Section 5 of [RFC4035] says little about validating responses based
   on (or that should be based on) CNAMEs. 

* The wording above is confusing or misleading. RFC 4035 Section 5 says 
nothing about CNAME specifically.

5.3.  Private Algorithms

...

   In the remaining cases, the security status of the zone depends on
   whether or not the resolver supports any of the private algorithms in
   use (provided that these DS records use supported hash functions, as
   discussed in Section 5.2).

* This may be confusing since the draft's section 5.2 matches up with 
numbering of RFC 4035's Section 5.2 and the draft's 5.2 does not use the 
terminology "hash functions".

5.6.  Setting the DO Bit on Replies

* Mention is is Section 3.

5.7.  Setting the AD Bit on Queries

The use of the AD bit in the query was previously undefined.

* It was defined for queries. See RFC 4035 4.6: ``A security-aware 
resolver MUST clear the AD bit when composing query messages to protect 
against buggy name servers that blindly copy header bits that they do 
not understand from the query message to the response message.''

6.1.  Finding Zone Cuts

* What are the "special rules" and "special processing rules"?  The 
wording is unclear if these are the rules defined in RFC 4035 3.1.4.1 or 
if they are new special rules.  In other words, what is the minor 
correction or clarification here?

Appendix B.  Discussion of Setting the CD Bit

* Maybe mention "(server failure)" in first mention of RCODE=2.

* Also be consistent with referring to RFC numbers, maybe always use 
brackets around them every time.

----- End forwarded message -----

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

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 18 May 2012 07:56:52 -0400 (EDT)

Thank you for these comments.  I've proposed some textual changes to 
address these.  Assuming there's not objection, these will be pushed 
out after the IETF LC ends.

> nothing about CNAME specifically.

Good catch.  I propose changing to "...says nothing explicit about 
validating responses based on ..."

> terminology "hash functions".

I propose: "(provided that these DS records use supported message 
digest algorithms, as discussed in Section 5.2 of this document)".

> * Mention is is Section 3.

Done.

> not understand from the query message to the response message.''

What to do with it was defined, but there was no "use" for it.  Even 
so, this is a little unclear.  I propose:

        The semantics of the AD bit in the query were previously
        undefined.  Section 4.6 of RFC4035 instructed
        resolvers to always clear the AD bit when composing
        queries.  This document defines setting the AD bit in a
        query...

> correction or clarification here?

There isn't one.  This is just restating something that should be 
obvious.  I don't even remember what inspired including this section 
-- it dates from the pre-WG draft, which started over seven(!) years 
ago.

It might be better to just take this out.  For the moment, I propose 
trimming the section to:

 	Appendix C.8 of RFC4035 discusses sending
 	DS queries to the servers for a parent zone but doesn't say
 	how to find those servers.  Specific instructions can be
 	found in Section 4.2 of RFC4035.

> * Maybe mention "(server failure)" in first mention of RCODE=2.

Done.

> brackets around them every time.

I changed the 4035 reference at the top of Appendix B.  I'll try to 
look for others later.

-- Sam