[dnsext] Protocol Action: 'Signaling Cryptographic Algorithm Understanding in DNSSEC' to Proposed Standard (draft-ietf-dnsext-dnssec-algo-signal-10.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Signaling Cryptographic Algorithm Understanding in DNSSEC'
  (draft-ietf-dnsext-dnssec-algo-signal-10.txt) as Proposed Standard

This document is the product of the DNS Extensions Working Group.

The IESG contact persons are Ted Lemon and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal/




Technical Summary

  The DNS Security Extensions (DNSSEC) were developed to provide
  origin authentication and integrity protection for DNS data by using
  digital signatures. These digital signatures can be generated using
  different algorithms. This draft sets out to specify a way for
  validating end-system resolvers to signal to a server which digital
  signature and hash algorithms they support. 

Working Group Summary

  The DNSEXT WG members reviewed and commented on previous revisions
  of the  document. All substantive comments were reviewed and the
  document updated accordingly. Most reviewers feel that the proposed
  extensions would be harmless to the protocol and would be useful for
  measuring cryptographic algorithm implementation uptake in
  clients. A minority of the reviewers questioned the need for such
  signalling. No reviewers flagged the existence of the proposed EDNS0
  extension create interoperability or deployment problems.

Document Quality

  The document does not change any protocol or change client or server
  processing in any significant way, but proposes a new option to
  EDNS(0) to aid authoritative DNS zone administrators to measure
  cryptograpic algorithm code in clients. 

Personnel

  Patrik Fältström is the Document Shepherd, and Ted Lemon is the
  Responsible Area Director. 

RFC Editor Note

Please make the following changes, to which the authors have agreed:

Section 1 Introduction

OLD: 
Each digital signature RR (RRSIG) contains an algorithm code number.

NEW:
Each digital signature (RRSIG) RR contains an algorithm code number that corresponds to a DNSSEC public key (DNSKEY RR).

OLD:
Likewise, Delegation Signer (DS) RRs and NSEC3 RRs use a hashed value as part of their RDATA

NEW:
Likewise, Delegation Signer (DS) RRs and Hashed Authenticated Denial of Existence (NSEC3) RRs use a hashed value as part of their RDATA


OLD:
These proposed EDNS options serve to measure the acceptance and use of new digital signing algorithms.  

NEW:
These proposed EDNS0 options serve to measure the acceptance and use of new digital signing algorithms.  

Section 2 Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood
   (DHU) and NSEC3 Hash Understood (N3U) Using EDNS

OLD:
These options are contained in the RDATA of the OPT meta-RR.  This document defines three new EDNS options for a client to signal which digital signature and/or hash algorithms the client supports.

NEW:
These options are contained in the resource record data (RDATA) of the OPT meta-RR.  This document defines three new EDNS0 options for a client to signal which digital signature and/or hash algorithms the client supports.  

Section 3.1.1
OLD:
A validating stub resolver already (usually) sets the DO bit
  [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs
  (i.e.  RRSIG RRs) in the response.  Such validating resolvers SHOULD
  include the DAU, DHU and/or the N3U option(s) in the OPT RR when
  sending a query.

NEW:
A validating stub resolver sets the DO bit
 [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs
 (i.e.  RRSIG RRs) in the response.  Such validating resolvers SHOULD
 include the DAU, DHU and/or the N3U option(s) in the OPT RR when
 sending a query. 


Section 3.2.1

OLD:
If the client did include the DO and CD bits, but did not include the DAU, DHU and/or N3U option(s) in the query, 

NEW:
If the client did include the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU and/or N3U option(s) in the query, 

In Section 4:
OLD
   Intermediate proxies [RFC5625] that understand DNS are
   RECOMMENDED to
NEW:
   Intermediate proxies [RFC5625-442] that understand DNS are
   RECOMMENDED to

Section 5

OLD:
If the options are present but the DNSSEC-OK (OK) bit is not set,

NEW:
If the options are present but the DNSSEC-OK (DO) bit is not set,

In Section 9:
OLD:
   [RFC5625]                           Bellis, R., "DNS Proxy
                                       Implementation Guidelines",
                                       BCP 152, RFC 5625, August 2009.
NEW:
   [RFC5625-442]                           Bellis, R., "DNS Proxy
                                       Implementation Guidelines",
                                       BCP 152, RFC 5625 section 4.4.2, August 2009.