Re: [secdir] Review of draft-ietf-dnsop-rfc4641bis-12

[Shawn Emery <[e-mail]>]

On 08/28/12 03:09 AM, Matthijs Mekking wrote:
> On 08/28/2012 09:22 AM, Shawn Emery wrote:
>> 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.
>>
>> This informational draft describes the operational practices for
>> administrating a DNSSEC environment.  Specifically the management of
>> keys and signatures in DNS.  The draft intends to obsolete RFC 4641.
>>
>> The security considerations section does exist and is somewhat terse in
>> its explanation of mitigating spoofing and DoS attacks.  This should be
>> expanded or at least a reference made.
> How DNSSEC mitigates against spoofing attacks and does not protect
> against DoS attacks is explained in the DNSSEC RFCs (RFC 4033-4035). I
> have added a reference to these documents. Also, I have explained a bit
> more how not taking into account 'data propagation' properties will
> cause validation failures, making secured zones unavailable to
> security-aware resolvers. The proposed text is now:
>
>
>     DNSSEC adds data origin authentication and data integrity to the DNS,
>     using digital signatures over resource record sets.  DNSSEC does not
>     protect against denial of service attacks, nor does it provide
>     confidentiality.  For more general security considerations related to
>     DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC
>     4035 [RFC4035].
>
>     This document tries to assess the operational considerations to
>     maintain a stable and secure DNSSEC service.  When performing key
>     rollovers, it is important to keep in mind that it takes time for the
>     data to be propagated to the verifying clients.  Also important to
>     notice is that this data may be cached.  Not taking into account the
>     'data propagation' properties in the DNS may cause validation
>     failures, because cached data may mismatch with data fetched from the
>     authoritative servers.  This will make secured zones unavailable to
>     security-aware resolvers.
>
>
> Is this better?

Yes, this resolves my concerns.  Thanks.

>> General comments:
>>
>> None.
>>
>> Editorial comments:
>>
>> Consistency: SEP is expanded, but not DS.
> I have expanded DS at its first occurrence.
>
>> s/purposes X will somewhere/purposes, X will be somewhere/
>> s/such as e.g.  RFC 5011/e.g. RFC 5011/
> Changed.
>
> The diff with the work in progress can be found here:
>
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-12.txt&url2=http://www.nlnetlabs.nl/~matje/draft-ietf-dnsop-rfc4641bis.txt
>
> tinyurl: http://tinyurl.com/8luvedk
>
> The diff also contains other reviewers changes.

These updates look good.

Regards,

Shawn.
--