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

From: Shawn Emery <[email-masked]>
Date: Tue, 28 Aug 2012 01:22:12 -0600

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.

General comments:

None.

Editorial comments:

Consistency: SEP is expanded, but not DS.

s/purposes X will somewhere/purposes, X will be somewhere/
s/such as e.g.  RFC 5011/e.g. RFC 5011/

Shawn.
--

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 28 Aug 2012 11:09:55 +0200

Hi Shawn,

Thanks for your review.

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

> Consistency: SEP is expanded, but not DS.

I have expanded DS at its first occurrence.

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

Best regards,
  Matthijs

---

From: Shawn Emery <[email-masked]>
Date: Wed, 29 Aug 2012 01:52:54 -0600

>     security-aware resolvers.

Yes, this resolves my concerns.  Thanks.

> The diff also contains other reviewers changes.

These updates look good.

Regards,

Shawn.
--