GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8145

Internet Engineering Task Force (IETF) D. Wessels Request for Comments: 8145 Verisign Category: Standards Track W. Kumari ISSN: 2070-1721 Google

                                                            P. Hoffman
                                                                 ICANN
                                                            April 2017
Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)

Abstract

 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 two different
 ways for validating resolvers to signal to a server which keys are
 referenced in their chain of trust.  The data from such signaling
 allow zone administrators to monitor the progress of rollovers in a
 DNSSEC-signed zone.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc8145.

Wessels, et al. Standards Track [Page 1] RFC 8145 DNSSEC Key Tag Signaling April 2017

Copyright Notice

 Copyright (c) 2017 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
    1.1. Design Evolution ...........................................4
 2. Requirements Terminology ........................................5
 3. Terminology .....................................................5
 4. Using the edns-key-tag Option ...................................5
    4.1. Option Format ..............................................5
    4.2. Use by Queriers ............................................6
         4.2.1. Stub Resolvers ......................................7
                4.2.1.1. Validating Stub Resolvers ..................7
                4.2.1.2. Non-validating Stub Resolvers ..............7
         4.2.2. Recursive Resolvers .................................7
                4.2.2.1. Validating Recursive Resolvers .............7
                4.2.2.2. Non-validating Recursive Resolvers .........8
    4.3. Use by Responders ..........................................8
 5. Using the Key Tag Query .........................................8
    5.1. Query Format ...............................................8
    5.2. Use by Queriers ............................................9
    5.3. Use by Responders ..........................................9
         5.3.1. Interaction with Aggressive Negative Caching ........9
 6. IANA Considerations ............................................10
 7. Security Considerations ........................................10
 8. Privacy Considerations .........................................11
 9. References .....................................................11
    9.1. Normative References ......................................11
    9.2. Informative References ....................................12
 Acknowledgments ...................................................13
 Authors' Addresses ................................................13

Wessels, et al. Standards Track [Page 2] RFC 8145 DNSSEC Key Tag Signaling April 2017

1. Introduction

 The DNS Security Extensions (DNSSEC) [RFC4033] [RFC4034] [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 resource record (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.
 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.
 This document specifies how validating resolvers can tell a server,
 in a DNS query, which DNSSEC key(s) they would use to validate the
 server's responses.  It describes two independent methods for
 conveying Key Tag information between clients and servers:
 1.  placing an EDNS option in the OPT RR [RFC6891] that contains the
     Key Tags (described in Section 4)
 2.  periodically sending special "Key Tag queries" to a server
     authoritative for the zone (described in Section 5)
 Each of these new signaling mechanisms is OPTIONAL to implement and
 use.  These mechanisms serve to measure the acceptance and use of new
 DNSSEC trust anchors and key signing keys (KSKs).  This signaling
 data 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
 that rely on [RFC5011] to automatically update a validating DNS
 resolver's trust anchor.
 This document does not introduce new processes for rolling keys or
 updating trust anchors.  Rather, it specifies a means by which a DNS
 query can signal the set of keys that a client uses for DNSSEC
 validation.

Wessels, et al. Standards Track [Page 3] RFC 8145 DNSSEC Key Tag Signaling April 2017

1.1. Design Evolution

 Initially, when the work on this document started, it proposed
 including Key Tag values in a new EDNS(0) option code.  It was
 modeled after [RFC6975], which provides DNSSEC algorithm signaling.
 The authors received feedback from participants in the DNSOP Working
 Group that it might be better to convey Key Tags in the QNAME of a
 separate DNS query, rather than as an EDNS(0) option.  Mostly, this
 is because forwarding (e.g., from stub to recursive to authoritative)
 could be problematic.  Reasons include the following:
 1.  EDNS(0) is a hop-by-hop protocol.  Unknown option codes would not
     be forwarded by default, as per [RFC6891].
 2.  Middleboxes might block entire queries containing unknown EDNS(0)
     option codes.
 3.  A recursive resolver might need to remember Key Tag values (i.e.,
     keep state) received from its stub clients and then forward them
     at a later opportunity.
 One advantage of the EDNS(0) option code is that it is possible to
 see that a stub client has a different Key Tag list than its
 forwarder.  In the QNAME-based approach, this is not possible because
 queries originated by a stub and a forwarder are indistinguishable.
 The authors feel that this advantage is not sufficient to justify the
 EDNS(0) approach.
 One downside to the QNAME approach is that it uses a separate query,
 whereas with EDNS(0) the Key Tag values are "piggybacked" onto an
 existing DNSKEY query.  For this reason, this document recommends
 only sending QNAME-based Key Tag queries for trust anchors, although
 EDNS-based Key Tags can be sent with any DNSKEY query.
 Another downside to the QNAME-based approach is that since the
 trust anchor zone might not contain labels matching the QNAME, these
 queries could be subject to aggressive negative caching features now
 in development by the Working Group.  This could affect the amount of
 signaling sent by some clients compared to others.
 A probably minor downside to the QNAME-based approach is that it
 cannot be used with extremely long query names if the addition of the
 prefix would cause the name to be longer than 255 octets.

Wessels, et al. Standards Track [Page 4] RFC 8145 DNSSEC Key Tag Signaling April 2017

2. Requirements Terminology

 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 [RFC2119].

3. Terminology

 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.  (This paragraph is
    quoted from Section 2 of [RFC4033].)
 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 [RFC4034], Appendix B.

4. Using the edns-key-tag Option

4.1. Option Format

 The edns-key-tag option is encoded as follows:
 0                       8                      16
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                  OPTION-CODE                  |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                 OPTION-LENGTH                 |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                    KEY-TAG                    |
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
 |                      ...                      /
 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Wessels, et al. Standards Track [Page 5] RFC 8145 DNSSEC Key Tag Signaling April 2017

 where:
 OPTION-CODE:  The EDNS0 option code assigned to edns-key-tag (14).
 OPTION-LENGTH:  The value 2 x number of key-tag values present.
 KEY-TAG:  One or more 16-bit Key Tag values ([RFC4034], Appendix B).

4.2. Use by Queriers

 A validating resolver sets the edns-key-tag option in the OPT RR when
 sending a DNSKEY query.  The validating resolver SHOULD also set the
 DNSSEC OK bit (also known as the DO bit) [RFC4035] to indicate that
 it wishes to receive DNSSEC RRs in the response.
 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY
 queries.
 The KEY-TAG value(s) included in the edns-key-tag option represents
 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 resolver learns the Key Tag(s) of the KSK(s) from the
 zone's DS record(s) (found in the parent) or from a trust anchor.
 A DNS client SHOULD include the edns-key-tag option when issuing a
 DNSKEY query for a zone corresponding to a trust anchor.
 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, a 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.
 A DNS client MUST NOT include Key Tag(s) for keys that are not
 learned via either a trust anchor or DS records.
 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.

Wessels, et al. Standards Track [Page 6] RFC 8145 DNSSEC Key Tag Signaling April 2017

4.2.1. Stub Resolvers

 Typically, stub resolvers rely on an upstream recursive resolver (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.

4.2.1.1. Validating Stub Resolvers

 A validating stub resolver sets the DNSSEC OK 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
 edns-key-tag option in the OPT RR when sending a DNSKEY query.

4.2.1.2. Non-validating Stub Resolvers

 The edns-key-tag option MUST NOT be included by non-validating stub
 resolvers.

4.2.2. Recursive Resolvers

4.2.2.1. Validating Recursive Resolvers

 A validating recursive resolver is, by definition, configured with at
 least one trust anchor.  Thus, a recursive resolver SHOULD include
 the edns-key-tag option in its DNSKEY queries as described above.
 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 and its own list.  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 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 resolver
 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.
 It is RECOMMENDED that implementations place reasonable limits on the
 number of Key Tags to include in the outgoing edns-key-tag option.

Wessels, et al. Standards Track [Page 7] RFC 8145 DNSSEC Key Tag Signaling April 2017

 If the client included the DNSSEC OK 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.
 Validating recursive resolvers MUST NOT set the edns-key-tag option
 in the final response to the stub client.

4.2.2.2. Non-validating Recursive Resolvers

 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.

4.3. Use by Responders

 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.
 A responder MUST NOT include the edns-key-tag option in any DNS
 response.

5. Using the Key Tag Query

5.1. Query Format

 A Key Tag query consists of a standard DNS query of type NULL and of
 class IN [RFC1035].
 The first component of the query name is the string "_ta-" followed
 by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
 values.  The zone name corresponding to the trust anchor is appended
 to this first component.
 For example, a validating DNS resolver that has a single root zone
 trust anchor with Key Tag 17476 (decimal) would originate a query of
 the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444.
 Hexadecimal values MUST be zero-padded to four hexadecimal digits.
 For example, if the Key Tag is 999 (decimal), it is represented in
 hexadecimal as 03e7.

Wessels, et al. Standards Track [Page 8] RFC 8145 DNSSEC Key Tag Signaling April 2017

 When representing multiple Key Tag values, they MUST be sorted in
 order from smallest to largest.  For example, a validating DNS
 resolver that has three trust anchors for the example.com zone with
 Key Tags 1589, 43547, 31406 (decimal) would originate a query of the
 form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com.

5.2. Use by Queriers

 A validating DNS resolver (stub or recursive) SHOULD originate a
 Key Tag query whenever it also originates a DNSKEY query for a
 trust anchor zone.  In other words, the need to issue a DNSKEY query
 is also the trigger to issue a Key Tag query.
 The value(s) included in the Key Tag query represents the Key Tag(s)
 of the trust anchor that will be used to validate the expected DNSKEY
 response.
 A validating DNS resolver SHOULD NOT originate Key Tag queries when
 also originating DNSKEY queries for non-trust anchor zones.
 A non-validating DNS resolver MUST NOT originate Key Tag queries.
 DNS resolvers with caches SHOULD cache and reuse the response to a
 Key Tag query just as it would any other response.

5.3. Use by Responders

 An authoritative name server receiving Key Tag queries MAY log or
 otherwise collect the Key Tag values to provide information to the
 zone operator.
 An authoritative name server MUST generate an appropriate response to
 the Key Tag query.  A server does not need to have built-in logic
 that determines the response to Key Tag queries: the response code is
 determined by whether the data is in the zone file or covered by
 wildcards.  The zone operator might want to add specific Key Tag
 records to its zone, perhaps with specific TTLs, to affect the
 frequency of Key Tag queries from clients.

5.3.1. Interaction with Aggressive Negative Caching

 Aggressive NSEC/NSEC3 negative caching [NSEC-NSEC3-Usage] may also
 affect the quality of Key Tag signaling.  When the response code for
 a Key Tag query is NXDOMAIN, DNS resolvers that implement aggressive
 negative caching will send fewer Key Tag queries than resolvers that
 do not implement it.

Wessels, et al. Standards Track [Page 9] RFC 8145 DNSSEC Key Tag Signaling April 2017

 For this reason, zone operators might choose to create records
 corresponding to expected Key Tag queries.  During a rollover from
 Key Tag 1111 (hex) to Key Tag 2222 (hex), the zone could include the
 following records:
 _ta-1111        IN   NULL   \# 0
 _ta-2222        IN   NULL   \# 0
 _ta-1111-2222   IN   NULL   \# 0
 Recall that when multiple Key Tags are present, the originating
 client MUST sort them from smallest to largest in the query name.

6. IANA Considerations

 IANA has assigned an EDNS0 option code for the edns-key-tag option in
 the "DNS EDNS0 Option Codes (OPT)" registry as follows:
            +-------+--------------+----------+-----------+
            | Value | Name         | Status   | Reference |
            +-------+--------------+----------+-----------+
            | 14    | edns-key-tag | Optional | RFC 8145  |
            +-------+--------------+----------+-----------+

7. Security Considerations

 This document specifies two ways for a client to signal its
 trust anchor knowledge to a cache or server.  The goal of these
 optional mechanisms 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.
 There is a possibility that an eavesdropper or server could infer the
 validator in use by a client by the Key Tag list seen.  This may
 allow an attacker to find validators using old, possibly broken,
 keys.  It could also be used to identify the validator or to narrow
 down the possible validator implementations in use by a client; the
 validator used by the client could have a known vulnerability that
 could be exploited by the attacker.
 Consumers of data collected from the mechanisms described in this
 document 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.

Wessels, et al. Standards Track [Page 10] RFC 8145 DNSSEC Key Tag Signaling April 2017

 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.

8. Privacy Considerations

 This proposal provides additional, optional "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 validating DNS clients.  This may be
 especially true if the validator is configured with trust anchors for
 zones in addition to the root zone.
 A validating resolver need not transmit the Key Tags in every
 applicable query.  Due to privacy concerns, such a resolver MAY
 choose to transmit the Key Tags for a subset of queries (e.g., every
 25th time) or by random chance with a certain probability (e.g., 5%).
 Implementations of this specification MAY be administratively
 configured to only transmit the Key Tags for certain zones.  For
 example, the software's configuration file may specify a list of
 zones for which the use of the mechanisms described here 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.

9. References

9.1. Normative References

 [RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
            November 1987, <http://www.rfc-editor.org/info/rfc1035>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "DNS Security Introduction and Requirements",
            RFC 4033, DOI 10.17487/RFC4033, March 2005,
            <http://www.rfc-editor.org/info/rfc4033>.

Wessels, et al. Standards Track [Page 11] RFC 8145 DNSSEC Key Tag Signaling April 2017

 [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Resource Records for the DNS Security Extensions",
            RFC 4034, DOI 10.17487/RFC4034, March 2005,
            <http://www.rfc-editor.org/info/rfc4034>.
 [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Protocol Modifications for the DNS Security
            Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
            <http://www.rfc-editor.org/info/rfc4035>.
 [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
            for DNS (EDNS(0))", STD 75, RFC 6891,
            DOI 10.17487/RFC6891, April 2013,
            <http://www.rfc-editor.org/info/rfc6891>.

9.2. Informative References

 [NSEC-NSEC3-Usage]
            Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
            DNSSEC-validated Cache", Work in Progress,
            draft-ietf-dnsop-nsec-aggressiveuse-09, March 2017.
 [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
            Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
            September 2007, <http://www.rfc-editor.org/info/rfc5011>.
 [RFC6975]  Crocker, S. and S. Rose, "Signaling Cryptographic
            Algorithm Understanding in DNS Security Extensions
            (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
            <http://www.rfc-editor.org/info/rfc6975>.

Wessels, et al. Standards Track [Page 12] RFC 8145 DNSSEC Key Tag Signaling April 2017

Acknowledgments

 This document was inspired by and borrows heavily from [RFC6975] by
 Scott Rose and Steve Crocker.  The authors would like to thank Mark
 Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim
 Wicinski, Suzanne Woolf, and other members of the DNSOP Working Group
 for their input.

Authors' Addresses

 Duane Wessels
 Verisign
 12061 Bluemont Way
 Reston, VA  20190
 United States of America
 Phone: +1 703 948-3200
 Email: dwessels@verisign.com
 URI:   http://verisigninc.com
 Warren Kumari
 Google
 1600 Amphitheatre Parkway
 Mountain View, CA  94043
 United States of America
 Email: warren@kumari.net
 Paul Hoffman
 ICANN
 Email: paul.hoffman@icann.org

Wessels, et al. Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8145.txt · Last modified: 2017/04/11 23:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki