One document matched: draft-ietf-dnsop-edns-key-tag-00.xml
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC5966 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5966.xml">
<!ENTITY RFC0768 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC1034 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1123 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1123.xml">
<!ENTITY RFC2119 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2119 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2629 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC2671 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2671.xml">
<!ENTITY RFC2920 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2920.xml">
<!ENTITY RFC3552 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3757 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3757.xml">
<!ENTITY RFC4033 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC5011 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY RFC5155 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml">
<!ENTITY RFC5358 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5358.xml">
<!ENTITY RFC5625 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5625.xml">
<!ENTITY RFC5625 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5625.xml">
<!ENTITY RFC6824 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6824.xml">
<!ENTITY RFC6891 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY RFC6975 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6975.xml">
<!ENTITY RFC7230 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml">
<!ENTITY RFC7323 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-dnsop-edns-key-tag-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="EDNS Key Tag Option">The EDNS Key Tag Option</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>Verisign Labs</organization>
<address>
<postal>
<street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
</postal>
<phone>+1 703 948-3200</phone>
<email>dwessels@verisign.com</email>
<uri>http://verisigninc.com</uri>
</address>
</author>
<date month="December" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>DNS</keyword>
<keyword>TCP/IP</keyword>
<keyword>transport</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<!-- text liberally borrowed from RFC 6975 -->
<abstract>
<t>
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
verified by building 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 validating end-system
resolvers to signal to a server which keys are referenced in
their chain-of-trust. The extensions allow zone administrators
to monitor the progress of rollovers in a DNSSEC-signed zone.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The DNS Security Extensions (DNSSEC) <xref target="RFC4033"/>,
<xref target="RFC4034"/> and <xref target="RFC4035"/> were developed
to provide origin
authentication and integrity protection for DNS data by using digital
signatures. 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 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 value is equal to the Key Tag of the DNSKEY RR that validates
the signature.
</t>
<t>
Likewise, Delegation Signer (DS) RRs also contain a Key Tag field whose
value is equal to the Key Tag of the DNSKEY RR to which it refers.
</t>
<t>
This draft sets out to specify a way for validating end-system
resolvers to tell a server in a DNS query which DNSSEC key(s) they
would use to validate the expected response. This is done using the
new EDNS option specified below in <xref target="option-format"/> for use in the
OPT meta-RR <xref target="RFC6891"/>.
This new EDNS option code is OPTIONAL to implement and use.
</t>
<t>
This proposed EDNS option serves to measure the
acceptance and use of new trust anchors and key signing keys (KSKs).
This signaling option can be used by zone administrators as a gauge
to measure the successful deployment of new keys. This is of particular
interest for the DNS root zone in the event of key and/or algorithm rollovers which
relies on <xref target="RFC5011"/> to automatically update a validating end-system's
trust anchor.
</t>
<t>
This draft does not seek to introduce another process for rolling keys or updating
trust anchors.
Rather, this document specifies a means by which a client
query can signal the set of keys that a client uses for DNSSEC validation.
</t>
</section>
<section title="Requirements Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="Trust Anchor:">A configured
DNSKEY RR or DS RR hash of a DNSKEY RR. A validating
security-aware resolver uses this public key or hash as a
starting point for building the authentication chain to a
signed DNS response. In general, a validating resolver
will have to obtain the initial values of its trust anchors
via some secure or trusted means outside the DNS protocol.
Presence of a trust anchor also implies that the resolver
should expect the zone to which the trust anchor points to
be signed. (quoted from <xref target="RFC4033"/> Section 2)</t>
<t hangText="Key Tag:">A 16-bit integer that identifies and enables efficient
selection of DNSSEC public keys. A Key Tag value can be
computed over the RDATA of a DNSKEY RR. The Key Tag field
in the RRSIG and DS records can be used to help select
the corresponding DNSKEY RR efficiently when more than
one candidate DNSKEY RR is available. For most algorithms
the Key Tag is a simple 16-bit modular sum of the DNSKEY
RDATA. See <xref target="RFC4034"/> Appendix B.</t>
</list>
</t>
</section>
<section title="Option Format" anchor="option-format">
<t>The edns-key-tag option is encoded as follows:</t>
<figure><artwork align="left"><![CDATA[
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY-TAG |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ... /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork></figure>
<t>where:
<list style="hanging">
<t hangText="OPTION-CODE: ">The EDNS0 option code
assigned to edns-key-tag, [TBD].</t>
<t hangText="OPTION-LENGTH: ">The value 2 x number of key-tag values present.</t>
<t hangText="KEY-TAG: ">One or more 16-bit Key Tag values (<xref target="RFC4034"/>, Appendix B).</t>
</list>
</t>
</section>
<section title="Use By Queriers">
<t>
A validating end-system resolver sets the edns-key-tag
option in the OPT meta-RR when sending a
DNSKEY query. The validating end-system resolver SHOULD also set the DNSSEC
OK bit <xref target="RFC4034"/> to indicate that it wishes to receive DNSSEC RRs in
the response.
</t>
<t>
A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY queries.
</t>
<t>
The KEY-TAG value(s) included in the edns-key-tag option represent the
Key Tag of the Trust Anchor or DNSKEY RR that will be used to validate the expected response.
When the client sends a DNSKEY query, the edns-key-tag option represents
the Key Tag(s) of the KSK(s) of the zone for which the server is authoritative.
A validating end-system resolver learns the Key Tag(s) of the KSK(s) from the zone's
DS record(s) (found in the parent), or from a configured trust anchor.
</t>
<t>
A DNS client SHOULD include the edns-key-tag option when issuing a DNSKEY
query for a zone corresponding to a configured Trust Anchor.
</t>
<t>
A DNS client MAY include the edns-key-tag option when issuing
a DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags
learned via DS records). Since some DNSSEC validators
implement bottom-up validation, non-Trust Anchor Key Tags
zone might not be known at the time of the query. Such a
validator can include the edns-key-tag option based on
previously cached data.
</t>
<t>
A DNS client MUST NOT include Key Tag(s) for keys which are
not learned via either configured Trust Anchor or DS records.
</t>
<t>
Since the edns-key-tag option is only set in the query, if
a client sees these options in the response, no action needs to be
taken and the client MUST ignore the option values.
</t>
<section title="Stub Resolvers">
<t>
Typically, stub resolvers rely on an upstream recursive server (or
cache) to provide a response. Optimal setting of the edns-key-tag
option depends on whether the stub resolver elects to
perform its own validation.
</t>
<section title="Validating Stub Resolvers">
<t>
A validating stub resolver sets the DNSSEC OK (DO) bit <xref target="RFC4034"/> to
indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG
RRs) in the response. Such validating resolvers SHOULD include the
edns-key-tag option in the OPT RR when sending a DNSKEY
query.
</t>
</section>
<section title="Non-validating Stub Resolvers">
<t>
The edns-key-tag option MUST NOT be included by
non-validating stub resolvers.
</t>
</section>
</section>
<section title="Recursive Resolvers">
<t></t>
<section title="Validating Recursive Resolvers">
<t>
A validating recursive resolver sets the edns-key-tag
option when performing recursion based on relevant keys it knows
and any edns-key-tag values in the stub client query.
When the recursive server 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).
</t>
<t>
A validating recursive resolver MAY combine stub client Key Tag values
from multiple incoming queries into a single outgoing query. It is
RECOMMENDED that implementations place reasonable limits on the number of
Key Tags to include in the outgoing edns-key-tag option.
</t>
<t>
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 recursive resolver MAY include the option with its own
Key Tag values in full.
</t>
<t>
Validating recursive resolvers MUST NOT set the edns-key-tag
option in the final response to the stub client.
</t>
</section>
<section title="Non-validating Recursive Resolvers">
<t>
Recursive resolvers that do not validate responses SHOULD copy the edns-key-tag
option seen in received queries, as they represent the
wishes of the validating downstream resolver that issued the original
query.
</t>
</section>
</section>
</section>
<section title="Use By Responders">
<t>
An authoritative name server receiving queries with the
edns-key-tag option MAY log or otherwise collect the Key
Tag values to provide information to the zone operator.
</t>
<t>
A responder MUST NOT include the edns-key-tag option in any
DNS response.
</t>
</section>
<section title="IANA Considerations">
<t>The IANA is directed to assign an EDNS0 option code for
the edns-key-tag option from the DNS EDNS0 Option Codes (OPT)
registry as follows:</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Name</ttcol>
<ttcol>Status</ttcol>
<ttcol>Reference</ttcol>
<c>[TBA]</c>
<c>edns-key-tag</c>
<c>Optional</c>
<c>[This document]</c>
</texttable>
</section>
<section title="Security Considerations" anchor="security">
<t>
This document specifies a way for a client to signal its trust anchor
knowledge to a cache or server. The signals
are optional codes contained in the OPT meta-RR used with EDNS. The
goal of these options is to signal new trust anchor uptake in clients
to allow zone administrators to know when it is possible to
complete a key rollover in a DNSSEC-signed zone.
</t>
<t>
There is a possibility that an eavesdropper or server could infer the
validator in use by a client by the Key Tag list seen in queries.
This may allow an attacker to find validators using old, possibly broken, keys.
It could also be used to identify the
validator or narrow down the possible validator implementations in
use by a client, which could have a known vulnerability that could be
exploited by the attacker.
</t>
<t>
Consumers of data collected from the edns-key-tag option
are advised that provided Key Tag values might be "made up"
by some DNS clients with malicious or at least mischievous
intentions.
For example, an attacker with sufficient
resources might try to generate large numbers of queries
including only old Key Tag values, with the intention of
delaying the completion of a key rollover.
</t>
<t>
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 new key will have identical Key Tag values.
Zone operators relying on the edns-key-tag mechanism SHOULD
take care to ensure that new keys have unique Key Tag values.
</t>
</section>
<section title="Privacy Considerations" anchor="privacy">
<t>
This proposal adds additional "signaling" to DNS queries
in the form of Key Tag values. While Key Tag values
themselves are not considered private information, it may
be possible for an eavesdropper to use Key Tag values as a
fingerprinting technique to identify particular DNS validating
clients. This may be especially true if the validator is
configured with trust anchor for zones in addition to the
root zone.
</t>
<t>
A validating end-system resolver need not transmit the
edns-key-tag option in every applicable query. Due to
privacy concerns, such a 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 certain probability
(e.g., 5%).
</t>
<t>
Implementations of this specification MAY be administratively
configured to only transmit the edns-key-tag option for
certain zones. For example, the software's configuration
file may specify a list of zones for which use of the option
is allowed or denied. Since the primary motivation for
this specification is to provide operational measurement
data for root zone key rollovers, it is RECOMMENDED that
implementations at least include the edns-key-tag option
for root zone DNSKEY queries.
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
This document was inspired by and borrows heavily from <xref target="RFC6975"/>
by Scott Rose and Steve Crocker. The author would like to
thank to Casey Deccio and Burt Kalisky for early feedback.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC1034;
&RFC1035;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC6891;
</references>
<references title="Informative References">
&RFC5011;
&RFC6975;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:22 |