< draft-ietf-dnsop-kskroll-sentinel-09.txt   draft-ietf-dnsop-kskroll-sentinel-10.txt >
DNSOP G. Huston DNSOP G. Huston
Internet-Draft J. Damas Internet-Draft J. Damas
Intended status: Standards Track APNIC Intended status: Standards Track APNIC
Expires: September 27, 2018 W. Kumari Expires: October 5, 2018 W. Kumari
Google Google
March 26, 2018 April 3, 2018
A Root Key Trust Anchor Sentinel for DNSSEC A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-09 draft-ietf-dnsop-kskroll-sentinel-10
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 mechanism that particular node in the DNS. This document specifies a mechanism that
will allow an end user and third parties to determine the trusted key will allow an end user and third parties to determine the trusted key
state for the root key of the resolvers that handle that user's DNS state for the root key of the resolvers that handle that user's DNS
skipping to change at page 1, line 49 skipping to change at page 1, line 49
decimal. Apolgies to those who have began implmenting.] decimal. Apolgies to those who have began implmenting.]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 September 27, 2018. This Internet-Draft will expire on October 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 7 3. Sentinel Mechanism in Resolvers . . . . . . . . . . . . . . . 7
3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Special processing . . . . . . . . . . . . . . . . . . . 8 3.2. Special processing . . . . . . . . . . . . . . . . . . . 8
4. Processing Sentinel Results . . . . . . . . . . . . . . . . . 8 4. Processing Sentinel Results . . . . . . . . . . . . . . . . . 8
5. Sentinel Test Result Considerations . . . . . . . . . . . . . 10 5. Sentinel Test Result Considerations . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
response code that is returned by resolvers when DNSSEC validation response code that is returned by resolvers when DNSSEC validation
fails. If a browser or operating system has multiple resolvers fails. If a browser or operating system has multiple resolvers
configured, and those resolvers have different properties (for configured, and those resolvers have different properties (for
example, one performs DNSSEC validation and one does not), the example, one performs DNSSEC validation and one does not), the
sentinel mechanism might search among the different resolvers, or sentinel mechanism might search among the different resolvers, or
might not, depending on how the browser or operating system is might not, depending on how the browser or operating system is
configured. configured.
Note that the sentinel mechanism described here measures a very Note that the sentinel mechanism described here measures a very
different (and likely more useful) metric than [RFC8145]. RFC 8145 different (and likely more useful) metric than [RFC8145]. RFC 8145
relies on resolvers reporting the list of keys that they have to root relies on resolvers reporting towards the root servers a list of
servers. That reflects on how many resolvers will be impacted by a locally cached trust anchors for the root zone. Those reports can be
KSK roll, but not what the user impact of the KSK roll will be. used to infer how many resolvers may be impacted by a KSK roll, but
not what the user impact of the KSK roll will be.
1.1. Terminology 1.1. 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 RFC 2119. document are to be interpreted as described in RFC 2119.
2. Protocol Walkthrough Example 2. Protocol Walkthrough Example
[Ed note: This is currently towards the front of the document; we [Ed note: This is currently towards the front of the document; we
skipping to change at page 7, line 36 skipping to change at page 7, line 36
is currently trusting?" Labels containing "root-key-sentinel-not-ta- is currently trusting?" Labels containing "root-key-sentinel-not-ta-
<key-tag>" is used to answer the question "Is this the Key Tag *not* <key-tag>" is used to answer the question "Is this the Key Tag *not*
a trust anchor which the validating DNS resolver is currently a trust anchor which the validating DNS resolver is currently
trusting?" trusting?"
3.1. Preconditions 3.1. Preconditions
All of the following conditions must be met to trigger special All of the following conditions must be met to trigger special
processing inside resolver code: processing inside resolver code:
o The DNS response is DNSSEC validated, regardless of whether o The DNS response is DNSSEC validated
DNSSSEC validation was requested, and result of validation is
"Secure" o the result of validation is "Secure"
o the AD bit is to be set in the response
o The QTYPE is either A or AAAA (Query Type value 1 or 28) o The QTYPE is either A or AAAA (Query Type value 1 or 28)
o The OPCODE is QUERY o The OPCODE is QUERY
o The leftmost label of the original QNAME (the name sent in the o The leftmost label of the original QNAME (the name sent in the
Question Section in the orignal query) is either "root-key- Question Section in the orignal query) is either "root-key-
sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>" sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>"
If any one of the preconditions is not met, the resolver MUST NOT If any one of the preconditions is not met, the resolver MUST NOT
skipping to change at page 12, line 50 skipping to change at page 12, line 50
resolver, identified a number of places where it wasn't clear, and resolver, identified a number of places where it wasn't clear, and
provided very helpful text to address this. provided very helpful text to address this.
10. Change Log 10. Change Log
RFC Editor: Please remove this section! RFC Editor: Please remove this section!
Note that this document is being worked on in GitHub - see Abstract. Note that this document is being worked on in GitHub - see Abstract.
The below is mainly large changes, and is not authoritative. The below is mainly large changes, and is not authoritative.
From -09 to -10:
o Clarified the precondition list to specify that the resolver had
performed DNSSEC-validation by setting the AD bit in the response
o Clarified the language referring to the operation of RFC8145
signalling.
From -08 to -09: From -08 to -09:
o Incorporated Paul Hoffman's PR # 15 (Two issues from the o Incorporated Paul Hoffman's PR # 15 (Two issues from the
Hackathon) - https://github.com/APNIC-Labs/draft-kskroll-sentinel/ Hackathon) - https://github.com/APNIC-Labs/draft-kskroll-sentinel/
pull/15 pull/15
o Clarifies that the match is on the *original* QNAME. o Clarifies that the match is on the *original* QNAME.
From -08 to -07: From -08 to -07:
skipping to change at page 15, line 4 skipping to change at page 15, line 8
o Clarification that this is for the root. o Clarification that this is for the root.
o Changed the label template from _is-ta-<key-tag> to kskroll- o Changed the label template from _is-ta-<key-tag> to kskroll-
sentinel-is-ta-<key-tag>. This is because BIND (at least) will sentinel-is-ta-<key-tag>. This is because BIND (at least) will
not allow records which start with an underscore to have address not allow records which start with an underscore to have address
records (CNAMEs, yes, A/AAAA no). Some browsers / operating records (CNAMEs, yes, A/AAAA no). Some browsers / operating
systems also will not fetch resources from names which start with systems also will not fetch resources from names which start with
an underscore. an underscore.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc- RFC 4033, DOI 10.17487/RFC4033, March 2005,
editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[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, <https://www.rfc-editor.org/info/rfc5011>. September 2007, <https://www.rfc-editor.org/info/rfc5011>.
11.2. Informative References 11.2. Informative References
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC Anchor Knowledge in DNS Security Extensions (DNSSEC)",
8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc- RFC 8145, DOI 10.17487/RFC8145, April 2017,
editor.org/info/rfc8145>. <https://www.rfc-editor.org/info/rfc8145>.
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Joao Silva Damas Joao Silva Damas
Email: joao@apnic.net Email: joao@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Warren Kumari Warren Kumari
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 15 change blocks. 
20 lines changed or deleted 32 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/