Subject: [secdir] secdir review of draft-ietf-dnsext-axfr-clarify-13

From: Chris Lonvick <[email-masked]>
Date: Mon, 1 Mar 2010 13:24:13 -0800 (PST)

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Overall, I found no problems with the document.  It is well written and 
very explanatory.  The following notes and suggestions are editorial.

It would be nice to reference the security considerations of RFCs 1034 and 
1035 just to say that this specification doesn't add any new 
considerations, however those documents don't have any security 
considerations sections.  Would the authors then consider something like 
the following (which would be the first paragraph in Section 8):
    This document is a clarification of a mechanism outlined in RFCs 1034
    and 1035 and as such does not add any new security considerations.  The
    security considerations relevent to the deployment of this
    specification are noted in RFC 4033.

In my first reading of the document, I was unfamiliar with the term "mbz". 
I'd suggest expanding the acronym in one place.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 2 Mar 2010 07:06:57 -0800 (PST)

Hi Alfred,

On Tue, 2 Mar 2010, Alfred HÎnes wrote:

> Chris,
> thanks for your detailed review.  See detailed responses inline.
>
>> Hi,
>>
> Thanks for this former judgement in particular.
> It deemed specifically important for a topic that some years ago
> had caused controversies to be as clear and logically consistent
> as possible and to explain therein the reasons to write that
> document -- the very cursory text in STD 13 that essentially had
> laid the grounds for diverging exegesis.
>
>>
>> It would be nice to reference the security considerations of RFCs 1034
>> and 1035 just to say that this specification doesn't add any new
>> considerations sections.  Would the authors then consider something
>> like the following (which would be the first paragraph in Section 8):
>
>>     and 1035 and as such does not add any new security considerations.
>>     The security considerations relevent to the deployment of this
> Unless someone opposes, such text can be added, sure.
> But in that case, wouldn't RFC 3833 be a better choice than RFC 4033?
> RFC 4033 indeed contains considerations that go beyond DNSSEC, but
> the more generic security considerations for the DNS in general are
> in RFC 3833.  I suggest to add the following text:
>
> |  This document is a clarification of a mechanism outlined in RFCs 1034
> |  and 1035 and as such does not add any new security considerations.
> |  RFC 3833 [RFC3833] is devoted entirely to security considerations for
> |  the DNS; its Section 4.3 delineates zone transfer security aspects
> |  from the security threats addressed by DNSSEC.
>
> [ + add an entry [RFC3833] to Section 12.2 (Informative References). ]
>
> Does that make sense to you?

That does address my concern very well.  (Not being familiar with the 
DNSSEC RFCs I chose 4033 from your list of references as it was close 
enough from my quick scans. :)

>
>
>> In my first reading of the document, I was unfamiliar with the term
>> "mbz".  I'd suggest expanding the acronym in one place.
>
> The first appearance of "mbz" is in Section 2.1.1, enclosed in (single)
> quotes, and tagged with "-- see Note c)", where Note c) (at the bottom
> of page 9) contains the explanation:
>
>   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
>      it.
>
> 'mbz' is used more as a user-friendly symbol -- at first glance similar
> to "MUST be 0", but actually quite different -- for the classification
> of fields than a literal acronym (and hence also written on lowercase),
> and the common expansion "must be zero" deliberately has been omitted
> because of anecdotal evidence that implementors have understood that as
> an encouragement, or even requirement, to check for value 0 on receipt,
> which is contrary to what we want.

Ahh, now I see; that is your definition.  OK, I was looking for an acronym 
expansion.  I'm not going to object if you leave it as is.

>
> Note: Similar considerations apply to 'n/a' ( same section, Note b) ).

Yup, but that one I could figure out without a definition.  :-)

Best regards,
Chris

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 2 Mar 2010 15:45:35 +0100 (MEZ)

Chris,

> Chris

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+