Subject: [secdir] Assignments

From: Samuel Weiler <[email-masked]>
Date: Fri, 11 Sep 2009 09:56:50 -0400 (EDT)

Richard Barnes is next in the rotation.

Please try to complete last call reviews by the end of the last call. 
For documents on telechat, note that the deadline field shown below 
reflects the telechat date, even though last call likely expires (or 
expired) before then.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat 2009-09-24

Reviewer                 Deadline   Draft
Derek Atkins           TR2009-09-22 draft-ietf-roll-building-routing-reqs-06
Julien Laganier        T 2009-09-22 draft-ietf-sip-certs-09
Kurt Zeilenga          T 2009-09-22 draft-ietf-dnsext-dnssec-rsasha256-14

Last calls and special requests:

Reviewer                 Deadline   Draft
Derek Atkins             2009-09-17 draft-ietf-rohc-ipsec-extensions-hcoipsec-05
Rob Austein              2009-10-07 draft-reschke-rfc2731bis-02
Alan DeKok               2009-08-17 draft-turner-deviceowner-attribute-01
Shawn Emery              2009-08-04 draft-ietf-alto-problem-statement-02
Phillip Hallam-Baker     2009-08-18 draft-ietf-pmol-sip-perf-metrics-04
Steve Hanna              2009-08-14 draft-ietf-krb-wg-cross-problem-statement-04
Love Hornquist-Astrand   2009-03-31 draft-ietf-ipfix-mib-07
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Julien Laganier          2009-06-09 draft-ietf-enum-3761bis-04
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy             2009-07-02 draft-ietf-speermint-voip-consolidated-usecases-14
Sandy Murphy             2009-09-04 draft-ietf-rtgwg-ipfrr-framework-11
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2009-09-04 draft-ietf-mboned-lightweight-igmpv3-mldv2-05
Eric Rescorla            2009-09-07 draft-ietf-tls-rfc4366-bis-05
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-11
Stefan Santesson         2009-09-08 draft-ietf-l3vpn-2547bis-mcast-bgp-07
Juergen Schoenwaelder    2009-09-08 draft-ietf-l3vpn-2547bis-mcast-08
Yaron Sheffer            2009-09-14 draft-ietf-calsify-2446bis-09
Hannes Tschofenig        2009-04-23 draft-ietf-pce-monitoring-05
Hannes Tschofenig        2009-07-25 draft-ietf-pkix-ta-format-03
Hannes Tschofenig        2009-10-07 draft-carpenter-renum-needs-work-03
Tina TSOU                2009-09-15 draft-ietf-syslog-sign-27
Sean Turner              2009-09-14 draft-ietf-ipsecme-ikev2-resumption-07
Carl Wallace             2009-09-22 draft-ietf-dime-diameter-cmd-iana-01
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Sam Weiler               2009-09-23 draft-ietf-eai-downgraded-display-02
Brian Weis               2009-09-22 draft-ietf-mipshop-pfmipv6-09
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-03
Nico Williams            2009-09-22 draft-ietf-nfsv4-federated-fs-reqts-03
Tom Yu                   2009-09-22 draft-ietf-rmt-pi-alc-revised-08
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-04
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02
Larry Zhu                2009-09-17 draft-ietf-rohc-hcoipsec-11
Glen Zorn                2009-09-17 draft-ietf-rohc-ikev2-extensions-hcoipsec-09

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 16 Sep 2009 10:12:25 +0100

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 document details how to produce RSA/SHA-512 and RSA/SHA-256  
DNSKEY and RRSIG RRs in DNS.

I find the document more than adequately discusses and addresses  
security considerations.

I do note that the document appears to place an additional  
recommendation upon implementors of DNSSEC (in Section 5.1) yet does  
not "update" any DNSSEC specification.   It may be appropriate for  
this I-D to "update" (upon approval/publication) DNSSEC specifications.

Regards, Kurt

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Sep 2009 10:05:05 -0400

Hi,

Thanks for your review.  I apologise for not having responded sooner.
I was travelling on other business last week, and it meant that I
couldn't concentrate on this topic.  One note of explanation:

On Wed, Sep 16, 2009 at 10:12:25AM +0100, Kurt Zeilenga wrote:

> recommendation upon implementors of DNSSEC (in Section 5.1) yet does not 
> "update" any DNSSEC specification.   It may be appropriate for this I-D 
> to "update" (upon approval/publication) DNSSEC specifications.

We have been loathe to make this document the mechanism by which we
update the DNSSEC specifications effectively to make NSEC3 an overall
part of the DNSSEC specification.  The reason I (especially) have been
so reluctant is that we already have, in the DNS community, a long
history of complaints about apparently minor, tangential drafts making
major conceptual changes to the DNS specifications.  The idea is to
ensure that the change making NSEC3 a basic part of DNSSEC appears in
a document that is obviously about DNSSEC as such, and not just the
identifier of an algorithm that may or may not get implemented.

We in fact have a draft in process that is to contain this change.
It's draft-ietf-dnsext-dnssec-bis-updates.  It has been moving
somewhat slowly through the WG, but I believe it is on track to be
published soon.  The current text in that document is this:

2.1.  NSEC3 Support

   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
   records for hashed denial of existence.  Validator implementations
   are strongly encouraged to include support for NSEC3 because a number
   of highly visible zones are expected to use it.  Validators that do
   not support validation of responses using NSEC3 will likely be
   hampered in validating large portions of the DNS space.

   [RFC5155] should be considered part of the DNS Security Document
   Family as described by [RFC4033], Section 10.

All of that said, if you feel strongly that, in the absence of
publication of dnssec-bis-updates, the sha-2 draft ought to update
RFC4033, we can relucantly make the change.  In that case, we will
plan to leave the above text in dnssec-bis-updates anyway, in an
effort to make this point plain to a potentially wider audience.

Best regards,

Andrew (shepherd)

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.