< draft-ietf-dnsop-edns-key-tag-00.txt   draft-ietf-dnsop-edns-key-tag-01.txt >
Internet Engineering Task Force D. Wessels Internet Engineering Task Force D. Wessels
Internet-Draft Verisign Labs Internet-Draft Verisign
Intended status: Standards Track December 9, 2015 Intended status: Standards Track W. Kumari
Expires: June 11, 2016 Expires: September 10, 2016 Google
March 9, 2016
The EDNS Key Tag Option The EDNS Key Tag Option
draft-ietf-dnsop-edns-key-tag-00 draft-ietf-dnsop-edns-key-tag-01
Abstract Abstract
The DNS Security Extensions (DNSSEC) were developed to provide origin The DNS Security Extensions (DNSSEC) were developed to provide origin
authentication and integrity protection for DNS data by using digital authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be verified by building a signatures. These digital signatures can be verified by building a
chain-of-trust starting from a trust anchor and proceeding down to a chain-of-trust starting from a trust anchor and proceeding down to a
particular node in the DNS. This document specifies a way for particular node in the DNS. This document specifies a way for
validating end-system resolvers to signal to a server which keys are validating end-system resolvers to signal to a server which keys are
referenced in their chain-of-trust. The extensions allow zone referenced in their chain-of-trust. The extensions allow zone
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 11, 2016. This Internet-Draft will expire on September 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Use By Queriers . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Use By Queriers . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . . 5 5.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . 6
5.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . . 6 5.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . 6
5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 6 5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 6
5.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6 5.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6
5.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 5.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 7
6. Use By Responders . . . . . . . . . . . . . . . . . . . . . . . 6 6. Use By Responders . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and
[RFC4035] were developed to provide origin authentication and [RFC4035] were developed to provide origin authentication and
integrity protection for DNS data by using digital signatures. integrity protection for DNS data by using digital signatures.
DNSSEC uses Key Tags to efficiently match signatures to the keys from DNSSEC uses Key Tags to efficiently match signatures to the keys from
which they are generated. The Key Tag is a 16-bit value computed which they are generated. The Key Tag is a 16-bit value computed
from the RDATA portion of a DNSKEY RR using a formula not unlike a from the RDATA portion of a DNSKEY RR using a formula not unlike a
ones-complement checksum. RRSIG RRs contain a Key Tag field whose ones-complement checksum. RRSIG RRs contain a Key Tag field whose
skipping to change at page 3, line 33 skipping to change at page 3, line 33
would use to validate the expected response. This is done using the would use to validate the expected response. This is done using the
new EDNS option specified below in Section 4 for use in the OPT new EDNS option specified below in Section 4 for use in the OPT
meta-RR [RFC6891]. This new EDNS option code is OPTIONAL to meta-RR [RFC6891]. This new EDNS option code is OPTIONAL to
implement and use. implement and use.
This proposed EDNS option serves to measure the acceptance and use of This proposed EDNS option serves to measure the acceptance and use of
new trust anchors and key signing keys (KSKs). This signaling option new trust anchors and key signing keys (KSKs). This signaling option
can be used by zone administrators as a gauge to measure the can be used by zone administrators as a gauge to measure the
successful deployment of new keys. This is of particular interest successful deployment of new keys. This is of particular interest
for the DNS root zone in the event of key and/or algorithm rollovers for the DNS root zone in the event of key and/or algorithm rollovers
which relies on [RFC5011] to automatically update a validating end- that rely on [RFC5011] to automatically update a validating end-
system's trust anchor. system's trust anchor.
[ FOR WG DISCUSSION: There is some reluctance within the working
group to use EDNS0 to convey the key tags upstream. In particular
there is a concern that middleboxes might block messages with unknown
option codes. Also since EDNS0 is hop-by-hop, middleboxes and un-
upgraded recursives won't necessarily know whether or not the edns-
key-tag options should be forwarded. RFC6891 says: "OPTION-CODE
values not understood by a responder or requestor MUST be ignored."
draft-wkumari-dnsop-trust-management proposed encoding this
information in query names, but sufficient issues with this approach
were discovered that the authors of the above decided to abandon this
work. The authors of draft-ietf-dnsop-edns-key-tag are willing to
consider this alternative if so guided by the working group. ]
This draft does not seek to introduce another process for rolling This draft does not seek to introduce another process for rolling
keys or updating trust anchors. Rather, this document specifies a keys or updating trust anchors. Rather, this document specifies a
means by which a client query can signal the set of keys that a means by which a client query can signal the set of keys that a
client uses for DNSSEC validation. client uses for DNSSEC validation.
2. Requirements Terminology 2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 6, line 14 skipping to change at page 6, line 22
5.1.2. Non-validating Stub Resolvers 5.1.2. Non-validating Stub Resolvers
The edns-key-tag option MUST NOT be included by non-validating stub The edns-key-tag option MUST NOT be included by non-validating stub
resolvers. resolvers.
5.2. Recursive Resolvers 5.2. Recursive Resolvers
5.2.1. Validating Recursive Resolvers 5.2.1. Validating Recursive Resolvers
A validating recursive resolver sets the edns-key-tag option when A validating recursive resolver is, by definition, configured with at
performing recursion based on relevant keys it knows and any edns- least one trust anchor. Thus, a recursive resolver SHOULD include
key-tag values in the stub client query. When the recursive server the edns-key-tag option in its DNSKEY queries as described above.
receives a query with the option set, the recursive server SHOULD set
the edns-key-tag list for any outgoing iterative queries for that
resolution chain to a union of the stub client's Key Tag(s) and the
validating recursive resolver's Key Tag(s). For example, if the
recursive resolver's Key Tag list is (19036, 12345) and the stub's
list is (19036, 34567), the final edns-key-tag list would be (19036,
12345, 34567).
A validating recursive resolver MAY combine stub client Key Tag In addition, the clients of a validating recursive resolver might be
configured to do their own validation, with their own trust
anchor(s). When a validating recursive resolver receives a query
that includes the edns-key-tag option with a Key Tag list that
differs from its own, it SHOULD forward both the client's Key Tag
list as well as its own. When doing so, the recursive resolver
SHOULD transmit the two Key Tag lists using separate instances of the
edns-key-tag option code in the OPT meta-RR. For example, if the
recursive resolver's Key Tag list is (19036, 12345) and the stub/
client's list is (19036, 34567), the recursive would include the
edns-key-tag option twice: Once with values (19036, 12345) and once
with values (19036, 34567).
A validating recursive resolver MAY combine stub/client Key Tag
values from multiple incoming queries into a single outgoing query. values from multiple incoming queries into a single outgoing query.
It is RECOMMENDED that implementations place reasonable limits on the It is RECOMMENDED that implementations place reasonable limits on the
number of Key Tags to include in the outgoing edns-key-tag option. number of Key Tags to include in the outgoing edns-key-tag option.
If the client included the DO and Checking Disabled (CD) bits, but If the client included the DO and Checking Disabled (CD) bits, but
did not include the edns-key-tag option in the query, the validating did not include the edns-key-tag option in the query, the validating
recursive resolver MAY include the option with its own Key Tag values recursive resolver MAY include the option with its own Key Tag values
in full. in full.
Validating recursive resolvers MUST NOT set the edns-key-tag option Validating recursive resolvers MUST NOT set the edns-key-tag option
skipping to change at page 8, line 7 skipping to change at page 8, line 18
intention of delaying the completion of a key rollover. intention of delaying the completion of a key rollover.
DNSSEC does not require keys in a zone to have unique Key Tags. DNSSEC does not require keys in a zone to have unique Key Tags.
During a rollover there is a small possibility that an old key and a During a rollover there is a small possibility that an old key and a
new key will have identical Key Tag values. Zone operators relying new key will have identical Key Tag values. Zone operators relying
on the edns-key-tag mechanism SHOULD take care to ensure that new on the edns-key-tag mechanism SHOULD take care to ensure that new
keys have unique Key Tag values. keys have unique Key Tag values.
9. Privacy Considerations 9. Privacy Considerations
This proposal adds additional "signaling" to DNS queries in the form This proposal adds additional, optional "signaling" to DNS queries in
of Key Tag values. While Key Tag values themselves are not the form of Key Tag values. While Key Tag values themselves are not
considered private information, it may be possible for an considered private information, it may be possible for an
eavesdropper to use Key Tag values as a fingerprinting technique to eavesdropper to use Key Tag values as a fingerprinting technique to
identify particular DNS validating clients. This may be especially identify particular DNS validating clients. This may be especially
true if the validator is configured with trust anchor for zones in true if the validator is configured with trust anchor for zones in
addition to the root zone. addition to the root zone.
A validating end-system resolver need not transmit the edns-key-tag A validating end-system resolver need not transmit the edns-key-tag
option in every applicable query. Due to privacy concerns, such a option in every applicable query. Due to privacy concerns, such a
resolver MAY choose to transmit the edns-key-tag option for a subset resolver MAY choose to transmit the edns-key-tag option for a subset
of queries (e.g., every 25th time), or by random chance with a of queries (e.g., every 25th time), or by random chance with a
skipping to change at page 8, line 33 skipping to change at page 8, line 44
zones. For example, the software's configuration file may specify a zones. For example, the software's configuration file may specify a
list of zones for which use of the option is allowed or denied. list of zones for which use of the option is allowed or denied.
Since the primary motivation for this specification is to provide Since the primary motivation for this specification is to provide
operational measurement data for root zone key rollovers, it is operational measurement data for root zone key rollovers, it is
RECOMMENDED that implementations at least include the edns-key-tag RECOMMENDED that implementations at least include the edns-key-tag
option for root zone DNSKEY queries. option for root zone DNSKEY queries.
10. Acknowledgments 10. Acknowledgments
This document was inspired by and borrows heavily from [RFC6975] by This document was inspired by and borrows heavily from [RFC6975] by
Scott Rose and Steve Crocker. The author would like to thank to Scott Rose and Steve Crocker. The authors would like to thank Casey
Casey Deccio and Burt Kalisky for early feedback. Deccio, Burt Kalisky, Bob Harold, Tim Wicinski, Suzanne Woolf, and
other members of the dnsop working group for their input.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
skipping to change at page 9, line 37 skipping to change at page 10, line 5
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>. September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic
Algorithm Understanding in DNS Security Extensions Algorithm Understanding in DNS Security Extensions
(DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
<http://www.rfc-editor.org/info/rfc6975>. <http://www.rfc-editor.org/info/rfc6975>.
Author's Address Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication]
From -00 to -01:
o Changed how a recursive should combine a stub's key tag values
with its own. Previously it was to be a union of key tag values.
Now it is a separate instance of the option code for recursive and
stub.
o Added Warren as coauthor.
Authors' Addresses
Duane Wessels Duane Wessels
Verisign Labs Verisign
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States
Phone: +1 703 948-3200 Phone: +1 703 948-3200
Email: dwessels@verisign.com Email: dwessels@verisign.com
URI: http://verisigninc.com URI: http://verisigninc.com
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States
Email: warren@kumari.net
 End of changes. 16 change blocks. 
45 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/