< draft-ietf-dnsop-kskroll-sentinel-07.txt   draft-ietf-dnsop-kskroll-sentinel-08.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 21, 2018 W. Kumari Expires: September 25, 2018 W. Kumari
Google Google
March 20, 2018 March 24, 2018
A Sentinel for Detecting Trusted Keys in DNSSEC A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-07 draft-ietf-dnsop-kskroll-sentinel-08
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 10 skipping to change at page 2, line 10
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 September 21, 2018. This Internet-Draft will expire on September 25, 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 (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
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Bob, Charlie, Dave and Ed to be able to perform tests, and also would Bob, Charlie, Dave and Ed to be able to perform tests, and also would
like to be able to perform Internet-wide measurements of what the like to be able to perform Internet-wide measurements of what the
impact will be (and report this back to Alice). impact will be (and report this back to Alice).
Geoff sets an authoritative DNS server for example.com, and also a Geoff sets an authoritative DNS server for example.com, and also a
webserver (www.example.com). He adds three address records to webserver (www.example.com). He adds three address records to
example.com: example.com:
invalid.example.com. IN AAAA 2001:db8::1 invalid.example.com. IN AAAA 2001:db8::1
kskroll-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1 root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1
kskroll-sentinel-not-ta-02323.example.com. IN AAAA 2001:db8::1 root-key-sentinel-not-ta-02323.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. In a real deployment, the domain names need to be under examples. In a real deployment, the domain names need to be under
control of the researcher, and the addresses must be real, reachable control of the researcher, and the addresses must be real, reachable
addresses. addresses.
Geoff then DNSSEC signs the example.com zone, and intentionally makes Geoff then DNSSEC signs the example.com zone, and intentionally makes
the invalid.example.com record invalid/bogus (for example, by editing the invalid.example.com record invalid/bogus (for example, by editing
the signed zone and entering garbage for the signature). Geoff also the signed zone and entering garbage for the signature). Geoff also
configures his webserver to listen on 2001:db8::1 and serve a configures his webserver to listen on 2001:db8::1 and serve a
resource (for example, a 1x1 GIF, 1x1.gif) for all of these names. resource (for example, a 1x1 GIF, 1x1.gif) for all of these names.
The webserver also serves a webpage (www.example.com) which contains The webserver also serves a webpage (www.example.com) which contains
links to these 3 resources (http://invalid.example.com/1x1.gif, links to these 3 resources (http://invalid.example.com/1x1.gif,
http://kskroll-sentinel-is-ta-02323.example.com/1x1.gif, http://root-key-sentinel-is-ta-02323.example.com/1x1.gif,
http://kskroll-sentinel-not-ta-02323.example.com/1x1.gif). http://root-key-sentinel-not-ta-02323.example.com/1x1.gif).
Geoff then asks Bob, Charlie, Dave and Ed to browse to Geoff then asks Bob, Charlie, Dave and Ed to browse to
www.example.com. Using the methods described in this document, the www.example.com. Using the methods described in this document, the
users can figure out what their fate will be when the 11112 KSK is users can figure out what their fate will be when the 11112 KSK is
removed. removed.
Bob is not using a validating resolver. This means that he will be Bob is not using a validating resolver. This means that he will be
able to resolve invalid.example.com (and fetch the 1x1 GIF) - this able to resolve invalid.example.com (and fetch the 1x1 GIF) - this
tells him that the KSK roll does not affect him, and so he will be tells him that the KSK roll does not affect him, and so he will be
OK. OK.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
fetch the http://invalid.example.com/1x1.gif resource (the fetch the http://invalid.example.com/1x1.gif resource (the
invalid.example.com record is bogus, and none of his resolvers will invalid.example.com record is bogus, and none of his resolvers will
resolve it). He is able to fetch both of the other resources - from resolve it). He is able to fetch both of the other resources - from
this he knows (see the logic below) that he is using legacy, this he knows (see the logic below) that he is using legacy,
validating resolvers. The KSK sentinel method cannot provided him validating resolvers. The KSK sentinel method cannot provided him
with a definitive answer to the question of what root trust anchors with a definitive answer to the question of what root trust anchors
this resolver is using. this resolver is using.
Dave's resolvers implement the sentinel method, and have picked up Dave's resolvers implement the sentinel method, and have picked up
the new KSK. For the same reason as Charlie, he cannot fetch the the new KSK. For the same reason as Charlie, he cannot fetch the
"invalid" resource. His resolver resolves the kskroll-sentinel-is- "invalid" resource. His resolver resolves the root-key-sentinel-is-
ta-02323.example.com name normally (it contacts the example.com ta-02323.example.com name normally (it contacts the example.com
authoritative servers, etc); as it supports the sentinel mechanism, authoritative servers, etc); as it supports the sentinel mechanism,
just before Dave's recursive server send the reply to Dave's stub, it just before Dave's recursive server send the reply to Dave's stub, it
performs the KSK Sentinel check (see below). The QNAME starts with performs the KSK Sentinel check (see below). The QNAME starts with
"kskroll-sentinel-is-ta-", and the recursive resolver does indeed "root-key-sentinel-is-ta-", and the recursive resolver does indeed
have a key with the Key Tag of 02323 in its root trust store. This have a key with the Key Tag of 02323 in its root trust store. This
means that that this part of the KSK Sentinel check passes (it is means that that this part of the KSK Sentinel check passes (it is
true that Key Tag 02323 is in the trust anchor store), and the true that Key Tag 02323 is in the trust anchor store), and the
recursive resolver replies normally (with the answer provided by the recursive resolver replies normally (with the answer provided by the
authoritative server). Dave's recursive resolver then resolves the authoritative server). Dave's recursive resolver then resolves the
kskroll-sentinel-not-ta-02323.example.com name. Once again, it root-key-sentinel-not-ta-02323.example.com name. Once again, it
performs the normal resolution process, but because it implements KSK performs the normal resolution process, but because it implements KSK
Sentinel (and the QNAME starts with "kskroll-sentinel-not-ta-"), just Sentinel (and the QNAME starts with "root-key-sentinel-not-ta-"),
before sending the reply, it performs the KSK Sentinel check. As it just before sending the reply, it performs the KSK Sentinel check.
has 02323 in it's trust anchor store, the answer to "is this *not* a As it has 02323 in it's trust anchor store, the answer to "is this
trust anchor" is false, and so the recursive resolver does not reply *not* a trust anchor" is false, and so the recursive resolver does
with the answer from the authoritative server - instead, it replies not reply with the answer from the authoritative server - instead, it
with a SERVFAIL (note that replying with SERVFAIL instead of the replies with a SERVFAIL (note that replying with SERVFAIL instead of
original answer is the only mechanism that KSK Sentinel uses). This the original answer is the only mechanism that KSK Sentinel uses).
means that Dave cannot fetch "invalid", he can fetch "kskroll- This means that Dave cannot fetch "invalid", he can fetch "root-key-
sentinel-is-ta-02323", but he cannot fetch "kskroll-sentinel-not-ta- sentinel-is-ta-02323", but he cannot fetch "root-key-sentinel-not-ta-
02323". From this, Dave knows that he is behind an upgraded, 02323". From this, Dave knows that he is behind an upgraded,
validating resolver, which has successfully installed the new, 02323 validating resolver, which has successfully installed the new, 02323
KSK. KSK.
Just like Charlie and Dave, Ed cannot fetch the "invalid" record. Just like Charlie and Dave, Ed cannot fetch the "invalid" record.
This tells him that his resolvers are validating. When his This tells him that his resolvers are validating. When his
(upgraded) resolver performs the KSK Sentinel check for "kskroll- (upgraded) resolver performs the KSK Sentinel check for "root-key-
sentinel-is-ta-02323", it does *not* have the (new, 02323) KSK in sentinel-is-ta-02323", it does *not* have the (new, 02323) KSK in
it's trust anchor store. This means check fails, and Ed's recursive it's trust anchor store. This means check fails, and Ed's recursive
resolver converts the (valid) answer into a SERVFAIL error response. resolver converts the (valid) answer into a SERVFAIL error response.
It performs the same check for kskroll-sentinel-not-ta- It performs the same check for root-key-sentinel-not-ta-
02323.example.com; as it does not have the 02323 KSK, it is true that 02323.example.com; as it does not have the 02323 KSK, it is true that
this is not a trust anchor for it, and so it replies normally. This this is not a trust anchor for it, and so it replies normally. This
means that Ed cannot fetch the "invalid" resource, he also cannot means that Ed cannot fetch the "invalid" resource, he also cannot
fetch the "kskroll-sentinel-is-ta-02323" resource, but he can fetch fetch the "root-key-sentinel-is-ta-02323" resource, but he can fetch
the "kskroll-sentinel-not-ta-02323" resource. This tells Ed that his the "root-key-sentinel-not-ta-02323" resource. This tells Ed that
resolvers have not installed the new KSK. his resolvers have not installed the new KSK.
Geoff would like to do a large scale test and provide the information Geoff would like to do a large scale test and provide the information
back to Alice. He uses some mechanism such as causing users to go to back to Alice. He uses some mechanism such as causing users to go to
a web page to cause a large number of users to attempt to resolve the a web page to cause a large number of users to attempt to resolve the
three resources, and then analyzes the results of the tests to three resources, and then analyzes the results of the tests to
determine what percentage of users will be affected by the KSK determine what percentage of users will be affected by the KSK
rollover event. rollover event.
The above description is a simplified example - it is not anticipated The above description is a simplified example - it is not anticipated
that Bob, Charlie, Dave and Ed will actually look for the absence or that Bob, Charlie, Dave and Ed will actually look for the absence or
skipping to change at page 7, line 13 skipping to change at page 7, line 13
KSK roll, but not what the user impact of the KSK roll will be. KSK roll, but not what the user impact of the KSK roll will be.
3. Sentinel Mechanism in Resolvers 3. Sentinel Mechanism in Resolvers
DNSSEC-Validating resolvers that implement this mechanism MUST DNSSEC-Validating resolvers that implement this mechanism MUST
perform validation of responses in accordance with the DNSSEC perform validation of responses in accordance with the DNSSEC
response validation specification [RFC4035]. response validation specification [RFC4035].
This sentinel mechanism makes use of two special labels: This sentinel mechanism makes use of two special labels:
o kskroll-sentinel-is-ta-<key-tag> o root-key-sentinel-is-ta-<key-tag>
o kskroll-sentinel-not-ta-<key-tag> o root-key-sentinel-not-ta-<key-tag>
Note that the <key-tag> is specified in the DNS label as unsigned Note that the <key-tag> is specified in the DNS label as unsigned
decimal integer (as described in [RFC4034], section 5.3), but zero- decimal integer (as described in [RFC4034], section 5.3), but zero-
padded to five digits (for example, a Key Tag 42 would be represented padded to five digits (for example, a Key Tag 42 would be represented
in the label as 00042). in the label as 00042).
These labels trigger special processing in the resolver when These labels trigger special processing in the resolver when
responses from authoritative servers are received. Labels containing responses from authoritative servers are received. Labels containing
"kskroll-sentinel-is-ta-<key-tag>" is used to answer the question "Is "root-key-sentinel-is-ta-<key-tag>" is used to answer the question
this the Key Tag a trust anchor which the validating DNS resolver is "Is this the Key Tag a trust anchor which the validating DNS resolver
currently trusting?" Labels containing "kskroll-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 and result of validation is o The DNS response is DNSSEC validated and result of validation is
"Secure" "Secure"
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 QNAME is either "kskroll-sentinel-is-ta- o The leftmost label of the QNAME is either "root-key-sentinel-is-
<key-tag>" or "kskroll-sentinel-not-ta-<key-tag>" 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
alter the DNS response based on the mechanism in this document. alter the DNS response based on the mechanism in this document.
3.2. Special processing 3.2. Special processing
Responses which fullfill all of the preconditions in Section 3.1 Responses which fullfill all of the preconditions in Section 3.1
require special processing, depending on leftmost label in the QNAME. require special processing, depending on leftmost label in the QNAME.
First, the resolver determines if the numerical value of <key-tag> is First, the resolver determines if the numerical value of <key-tag> is
skipping to change at page 8, line 49 skipping to change at page 8, line 49
their DNS resolution system, and, in particular, whether or not they their DNS resolution system, and, in particular, whether or not they
are using one or more validating DNS resolvers that use a particular are using one or more validating DNS resolvers that use a particular
trust anchor for the root zone. trust anchor for the root zone.
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 process uses a test with three query names: The sentinel detection process uses a test with three query names:
o A query name containing the left-most label "kskroll-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 RRset in ta-<key-tag>". This corresponds to a a validly-signed RRset in
the zone, so that responses associated with queried names in this the zone, so that responses associated with queried names in this
zone can be authenticated by a DNSSEC-validating resolver. Any zone can be authenticated by a DNSSEC-validating resolver. Any
validly-signed DNS zone can be used for this test. validly-signed DNS zone can be used for this test.
o A query name containing the left-most label "kskroll-sentinel-not- o A query name containing the left-most label "root-key-sentinel-
ta-<key-tag>". This is also a validly-signed name. Any validly- not-ta-<key-tag>". This is also a validly-signed name. Any
signed DNS zone can be used for this test. validly-signed DNS zone can be used 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 (such as if the corresponding RRset is not signed with a validated (such as if the corresponding RRset is not signed with a
valid RRSIG record). valid RRSIG record).
The responses received from queries to resolve each of these names The responses received from queries to resolve each of these names
would allow us to infer a trust key state of the resolution would allow us to infer a trust key state of the resolution
environment. The techniques describes in this document rely on environment. The techniques describes in this document rely on
(DNSSEC validating) resolvers responding with SERVFAIL to valid (DNSSEC validating) resolvers responding with SERVFAIL to valid
answers. Note that a slew of other issues can also cause SERVFAIL answers. Note that a slew of other issues can also cause SERVFAIL
responses, and so the sentinel processing may sometimes result in responses, and so the sentinel processing may sometimes result in
incorrect conclusions. incorrect conclusions.
To describe this process of classification, we can classify resolvers To describe this process of classification, we can classify resolvers
into four distinct behavior types, for which we will use the labels: into four distinct behavior types, for which we will use the labels:
"Vnew", "Vold", "Vleg", and "nonV". These labels correspond to "Vnew", "Vold", "Vleg", and "nonV". These labels correspond to
resolver behaviour types as follows: resolver behaviour types as follows:
Vnew: A DNSSEC-Validating resolver that is configured to implement Vnew: A DNSSEC-Validating resolver that is configured to implement
this mechanism has loaded the nominated key into its local trusted this mechanism has loaded the nominated key into its local trusted
key store will respond with an A or AAAA RRset response for key store will respond with an A or AAAA RRset response for "root-
"kskroll-sentinel-is-ta" queries, SERVFAIL for "kskroll-sentinel- key-sentinel-is-ta" queries, SERVFAIL for "root-key-sentinel-not-
not-ta" queries and SERVFAIL for the invalidly signed name ta" queries and SERVFAIL for the invalidly signed name queries.
queries.
Vold: A DNSSEC-Validating resolver that is configured to implement Vold: A DNSSEC-Validating resolver that is configured to implement
this mechanism that has not loaded the nominated key into its this mechanism that has not loaded the nominated key into its
local trusted key store will respond with an SERVFAIL for local trusted key store will respond with an SERVFAIL for "root-
"kskroll-sentinel-is-ta" queries, an A or AAAA RRset response for key-sentinel-is-ta" queries, an A or AAAA RRset response for
"kskroll-sentinel-not-ta" queries and SERVFAIL for the invalidly "root-key-sentinel-not-ta" queries and SERVFAIL for the invalidly
signed name queries. signed name queries.
Vleg: A DNSSEC-Validating resolver that does not implement this Vleg: A DNSSEC-Validating resolver that does not implement this
mechanism will respond with an A or AAAA RRset response for mechanism will respond with an A or AAAA RRset response for "root-
"kskroll-sentinel-is-ta", an A or AAAA RRset response for key-sentinel-is-ta", an A or AAAA RRset response for "root-key-
"kskroll-sentinel-not-ta" and SERVFAIL for the invalid name. sentinel-not-ta" and SERVFAIL for the invalid name.
nonV: A non-DNSSEC-Validating resolver will respond with an A or nonV: A non-DNSSEC-Validating resolver will respond with an A or
AAAA record response for "kskroll-sentinel-is-ta", an A record AAAA record response for "root-key-sentinel-is-ta", an A record
response for "kskroll-sentinel-not-ta" and an A or AAAA RRset response for "root-key-sentinel-not-ta" and an A or AAAA RRset
response for the invalid name. response for the invalid name.
Given the clear delineation amongst these three cases, if a client Given the clear delineation amongst these three cases, if a client
directs these three queries to a simple resolver, the variation in directs these three queries to a simple resolver, the variation in
response to the three queries should allow the client to determine response to the three queries should allow the client to determine
the category of the resolver, and if it supports this mechanism, the category of the resolver, and if it supports this mechanism,
whether or not it has a particular key in its trust anchor store. whether or not it has a particular key in its trust anchor store.
Query Query
+----------+-----------+------------+ +----------+-----------+------------+
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 -07 to -06 From -08 to -07:
o Changed title from "A Sentinel for Detecting Trusted Keys in
DNSSEC" to "A Root Key Trust Anchor Sentinel for DNSSEC".
o Changed magic string from "kskroll-sentinel-" to "root-key-
sentinel-" -- this time for sure, Rocky!
From -07 to -06:
o Addressed GitHub PR #14: Clarifications regarding caching and o Addressed GitHub PR #14: Clarifications regarding caching and
SERVFAIL responses SERVFAIL responses
o Addressed GitHub PR #12, #13: Clarify situation with multiple o Addressed GitHub PR #12, #13: Clarify situation with multiple
resolvers, Fix editorial nits. resolvers, Fix editorial nits.
From -05 to -06: From -05 to -06:
o Paul improved my merging of Petr's text to make it more readable. o Paul improved my merging of Petr's text to make it more readable.
Minor change, but this is just before the cut-off, so I wanted it Minor change, but this is just before the cut-off, so I wanted it
 End of changes. 25 change blocks. 
50 lines changed or deleted 58 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/