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.
