draft-ietf-dnsop-kskroll-sentinel-16.txt   draft-ietf-dnsop-kskroll-sentinel-17.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: April 23, 2019 W. Kumari Expires: April 23, 2019 W. Kumari
Google Google
October 20, 2018 October 20, 2018
A Root Key Trust Anchor Sentinel for DNSSEC A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-16 draft-ietf-dnsop-kskroll-sentinel-17
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 2, line 42 skipping to change at page 2, line 42
4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 11 4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Implementation Experience . . . . . . . . . . . . . . . . . . 13 7. Implementation Experience . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Protocol Walkthrough Example . . . . . . . . . . . . 19 Appendix A. Protocol Walkthrough Example . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 of a DNSKEY RR as described in Appendix B of from the RDATA of a DNSKEY RR as described in Appendix B of
skipping to change at page 5, line 4 skipping to change at page 5, line 4
validating DNS resolver is currently trusting as a trust anchor?" validating DNS resolver is currently trusting as a trust anchor?"
Labels containing "root-key-sentinel-not-ta-<key-tag>" is used to Labels containing "root-key-sentinel-not-ta-<key-tag>" is used to
answer the question "Is this the Key Tag of a key which the answer the question "Is this the Key Tag of a key which the
validating DNS resolver is *not* currently trusting as a trust validating DNS resolver is *not* currently trusting as a trust
anchor?". anchor?".
The special labels defined here came after extensive IETF evaluation The special labels defined here came after extensive IETF evaluation
of alternative patterns and approaches in light of the desired of alternative patterns and approaches in light of the desired
behaviour (sections 2.1, 2.2) within the resolver and the applied behaviour (sections 2.1, 2.2) within the resolver and the applied
testing methodology (section 4.3). As one example, underscore testing methodology (section 4.3). As one example, underscore
prefixed names were rejected because a number of browsers / operating prefixed names were rejected because some browsers and operating
systems would not fetch them, as they were not viewed as valid systems would not fetch them because they domain names but not valid
"hostnames".Attention was paid to the consideration of local hostnames (see [RFC7719] for these definitions). Attention was paid
collisions and the reservation of Left Hand Side (LHS) labels of a to the consideration of local collisions and the reservation of
domain name, and the impact upon zone operators who might desire to leftmost labels of a domain name, and the impact upon zone operators
use a similarly constructed hostname for a purpose other than as who might desire to use a similarly constructed hostname for a
documented here. Therefore, it is important to note that the purpose other than as documented here. Therefore, it is important to
reservation of the labels in this manner is definitely not considered note that the reservation of the labels in this manner is definitely
"best practice". not considered "best practice".
2.1. Preconditions 2.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. o The DNS response is DNSSEC validated.
o The result of validation is "Secure". o The result of validation is "Secure".
skipping to change at page 7, line 6 skipping to change at page 7, line 6
user environment. user environment.
The critical aspect of the DNS names used in this mechanism is that The critical aspect of the DNS names used in this mechanism is that
they contain the specified label for either the positive and negative they contain the specified label for either the positive and negative
test as the left-most label in the query name. test as the left-most label in the query name.
The sentinel detection procedure can test a DNS resolver using three The sentinel detection procedure can test a DNS resolver using three
queries: queries:
o A query name containing the left-most label "root-key-sentinel-is- o A query name containing the left-most label "root-key-sentinel-is-
ta-<key-tag>". This corresponds to a a validly-signed label in ta-<key-tag>". This corresponds to a validly-signed name in the
the parent zone, so that responses associated with this query name parent zone, so that responses associated with this query name can
can be authenticated by a DNSSEC-validating resolver. Any be authenticated by a DNSSEC-validating resolver. Any validly-
validly-signed DNS zone can be used as the parent zone for this signed DNS zone can be used as the parent zone for this test.
test.
o A query name containing the left-most label "root-key-sentinel- o A query name containing the left-most label "root-key-sentinel-
not-ta-<key-tag>". This is also a validly-signed label. Any not-ta-<key-tag>". This also corresponds to a validly-signed
validly-signed DNS zone can be used as the parent zone for this name. Any validly-signed DNS zone can be used as the parent zone
test. for this test.
o A query name that is signed with a DNSSEC signature that cannot be o A query name that is signed with a DNSSEC signature that cannot be
validated (described as a "bogus" RRset in Section 5 of [RFC4033], validated (described as a "bogus" RRset in Section 5 of [RFC4033],
when, for example, an RRset associated with a label in a zoneis when, for example, an RRset associated with a zone that is not
not signed with a valid RRSIG record). signed with a valid RRSIG record).
The responses received from queries to resolve each of these query The responses received from queries to resolve each of these query
names can be evaluated to infer a trust key state of the DNS names can be evaluated to infer a trust key state of the DNS
resolver. resolver.
An essential assumption here is that this technique relies on An essential assumption here is that this technique relies on
security-aware (DNSSEC validating) resolvers responding with a security-aware (DNSSEC validating) resolvers responding with a
SERVFAIL response code to queries where DNSSEC checking is requested SERVFAIL response code to queries where DNSSEC checking is requested
and the response cannot be validated. Note that other issues can and the response cannot be validated. Note that other issues can
also cause a resolver to return SERVFAIL responses, and so the also cause a resolver to return SERVFAIL responses, and so the
skipping to change at page 8, line 51 skipping to change at page 8, line 51
+----------+-----------+------------+ +----------+-----------+------------+
| is-ta | not-ta | bogus | | is-ta | not-ta | bogus |
+-------+----------+-----------+------------+ +-------+----------+-----------+------------+
| Vnew | Y | SERVFAIL | SERVFAIL | | Vnew | Y | SERVFAIL | SERVFAIL |
| Vold | SERVFAIL | Y | SERVFAIL | | Vold | SERVFAIL | Y | SERVFAIL |
Type | Vind | Y | Y | SERVFAIL | Type | Vind | Y | Y | SERVFAIL |
| nonV | Y | Y | Y | | nonV | Y | Y | Y |
| other | * | * | * | | other | * | * | * |
+-------+----------+-----------+------------+ +-------+----------+-----------+------------+
In this table the 'Y' response denotes an A or AAAA RRset response In this table, the "Y" response denotes an A or AAAA RRset response
(depending on the Query Type of A or AAAA records), 'SERVFAIL' (depending on the query type of A or AAAA records), "SERVFAIL"
denotes a DNS SERVFAIL response code (RCODE 2), and '*' denotes denotes a DNS SERVFAIL response code (RCODE 2), and "*" denotes
either response. either response.
Vnew: The nominated key is trusted by the resolver. Vnew: The nominated key is trusted by the resolver.
Vold: The nominated key is not yet trusted by the resolver. Vold: The nominated key is not yet trusted by the resolver.
Vind: There is no information about the trust anchors of the Vind: There is no information about the trust anchors of the
resolver. resolver.
nonV: The resolver does not perform DNSSEC validation. nonV: The resolver does not perform DNSSEC validation.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
significant feedback (including pointing out when the test bed didn't significant feedback (including pointing out when the test bed didn't
match the document!) match the document!)
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 -16 to -17:
o Thank to Paul Hoffman for "Lots of editorial fixes for post-IESG
draft" ( https://github.com/APNIC-Labs/draft-kskroll-sentinel/
pull/28 )
o Repeat after me: Do not drive git while on cold meds...
From -15 to -16: From -15 to -16:
o Addressed IESG comments o Addressed IESG comments
o Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel o Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel
o Also added Terry's "This a bad design pattern, but we decided the o Also added Terry's "This a bad design pattern, but we decided the
benefits outweigh the costs this time." text. benefits outweigh the costs this time." text.
o Suggestion from Adam to clarify that bypassing e.g gethostbyname() o Suggestion from Adam to clarify that bypassing e.g gethostbyname()
skipping to change at page 20, line 41 skipping to change at page 20, line 52
webserver (www.example.com). He adds three address records to webserver (www.example.com). He adds three address records to
example.com: example.com:
bogus.example.com. IN AAAA 2001:db8::1 bogus.example.com. IN AAAA 2001:db8::1
root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1 root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1
root-key-sentinel-not-ta-11112.example.com. IN AAAA 2001:db8::1 root-key-sentinel-not-ta-11112.example.com. IN AAAA 2001:db8::1
Note that the use of "example.com" names and the addresses here are Note that the use of "example.com" names and the addresses here are
examples, and 'bogus' intentionally has invalid DNSSEC signatures. examples, and "bogus" intentionally has invalid DNSSEC signatures.
In a real deployment, the domain names need to be under control of In a real deployment, the domain names need to be under control of
the researcher, and the addresses must be real, reachable addresses. the researcher, and the addresses must be real, reachable addresses.
Geoff then DNSSEC signs the example.com zone, and intentionally makes Geoff then DNSSEC signs the example.com zone, and intentionally makes
the bogus.example.com record have bogus validation status (for the bogus.example.com record have bogus validation status (for
example, by editing the signed zone and entering garbage for the example, by editing the signed zone and entering garbage for the
signature). Geoff also configures his webserver to listen on signature). Geoff also configures his webserver to listen on
2001:db8::1 and serve a resource (for example, a 1x1 GIF, 1x1.gif) 2001:db8::1 and serve a resource (for example, a 1x1 GIF, 1x1.gif)
for all of these names. The webserver also serves a webpage for all of these names. The webserver also serves a webpage
(www.example.com) which contains links to these 3 resources (www.example.com) which contains links to these 3 resources
 End of changes. 9 change blocks. 
26 lines changed or deleted 34 lines changed or added

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