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

[Chris Lonvick <[e-mail]>]

Hi Alfred,

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

> Chris,
> thanks for your detailed review.  See detailed responses inline.
>
>> 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.
>
> 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, 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.
>
> 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