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

[Matthijs Mekking <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Shawn,

Thanks for your review.

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?


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

Best regards,
  Matthijs


> 
> Shawn.
> --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQPIrjAAoJEA8yVCPsQCW5RV8H/jQrXSXs1ZnJHFWvGeamL/MS
QG41CmBX0tYpW7QHT/YjcwBopXo/XuvHY3ITqMskeUfJjC5XNpvC5Uh2Gm+QZ5cs
jvikzNG6DaaXpCKSWuXskHsLFm8Pzfu9geUkpgbULtaJNgxCvG15+z+cLVSbuMoY
oZ7Gysec9kxklvqqTinfeMZAqNyROXew/lzTRYam6nlYePwAeV23h0Bu3JOm4yvd
DF1F1UhZaqEiaBk6vUuDepS76irBLzSHHxqHXQ7JlFIAO/TegemqF+OZ6Bhd+HNp
MlT5Tq+5nIF7+qR2oGD/j1sqnPxIJfI7dhdRB9aEXiJAx43m0WDZU+2k5f5HWL0=
=Idp2
-----END PGP SIGNATURE-----