draft-ietf-dnsop-kskroll-sentinel-05.txt   draft-ietf-dnsop-kskroll-sentinel-06.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 6, 2018 W. Kumari Expires: September 6, 2018 W. Kumari
Google Google
March 5, 2018 March 5, 2018
A Sentinel for Detecting Trusted Keys in DNSSEC A Sentinel for Detecting Trusted Keys in DNSSEC
draft-ietf-dnsop-kskroll-sentinel-05 draft-ietf-dnsop-kskroll-sentinel-06
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 6, line 40 skipping to change at page 6, line 40
and checking which result in a SERVFAIL. and checking which result in a SERVFAIL.
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 the list of keys that they have to root
servers. That reflects on how many resolvers will be impacted by a servers. That reflects on how many resolvers will be impacted by a
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 be DNSSEC-Validating resolvers that implement this mechanism MUST
performing 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 kskroll-sentinel-is-ta-<key-tag>
o kskroll-sentinel-not-ta-<key-tag> o kskroll-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 (i.e: 42 would be represented as 00042). padded to five digits (for example, a Key Tag 42 would be represented
in the label as 00042).
These labels trigger special processing in the resolver as specified
bellow. The labels containing "is-ta" and "not-ta" are used to
answer questions "Is (or is not, respectivaly) this the key tag a
trust anchor which the validating DNS resolver is currently
trusting?" Processing of both labels has the very same preconditions
for both labels and differs only in last step.
The use of the positive question and its inverse allows for queries These labels trigger special processing in the resolver when
to detect whether resolvers support this sentinel mechanism. responses from authoritative servers are received. Labels containing
"kskroll-sentinel-is-ta-<key-tag>" is used to answer the question "Is
this the Key Tag a trust anchor which the validating DNS resolver is
currently trusting?" Labels containing "kskroll-sentinel-not-ta-
<key-tag>" is used to answer the question "Is this the Key Tag *not*
a trust anchor which the validating DNS resolver is currently
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:
a. DNS response for particular query is DNSSEC validated and result o The DNS response is DNSSEC validated and result of validation is
of validation is SECURE. "Secure"
b. QTYPE is A or AAAA (Query Type value 1 or 28) o The QTYPE is either A or AAAA (Query Type value 1 or 28)
c. The OPCODE is QUERY o The OPCODE is QUERY
d. The leftmost label of the QNAME is either "kskroll-sentinel-is- o The leftmost label of the QNAME is either "kskroll-sentinel-is-ta-
ta-<tag-index>" or "kskroll-sentinel-not-ta-<tag-index>" <key-tag>" or "kskroll-sentinel-not-ta-<key-tag>"
If all preconditions are not met, the resolver MUST NOT alter the DNS If any one of the preconditions is not met, the resolver MUST NOT
response. alter the DNS response based on the mechanism in this document.
3.2. Special processing 3.2. Special processing
Responses which fullfill all preconditions in section 3.1 are subject Responses which fullfill all of the preconditions in Section 3.1
of special processing, depending on leftmost label of 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
equal to any of the key tags of an active Root Zone Key Signing Key equal to any of the Key Tags of an active root zone KSK which is
which is currently trusted by the local resolver and is stored in its currently trusted by the local resolver and is stored in its store of
store of trusted keys. An active key is one which could currently be trusted keys. An active key is one which could currently be used for
used for validation (that is, a key that is not in either the AddPend validation (that is, a key that is not in either the AddPend or
or Revoked state as described in [RFC5011]). Revoked state as described in [RFC5011]).
As second step, the resolver alters response depending on meaning of Second, the resolver alters the response being sent to the original
the label and presence of key with given keytag among trusted keys. query based on both the left-most label and the presence of a key
Two labels and two possible states of the keytag generate four with given Key Tag in the trust anchor store. Two labels and two
possible combinations summarized in the table: possible states of the keytag generate four possible combinations
summarized in the table:
Keytag trusted | Key Tag is trusted | Key Tag is not trusted
label type | yes | no ------------------------------------------------------------------
-------------------------------------------------------------- is-ta | return original answer | return SERVFAIL
is-ta | return original answer | return SERVFAIL not-ta | return SERVFAIL | return original answer
not-ta | return SERVFAIL | return original answer
4. Processing Sentinel Results 4. Processing Sentinel Results
This proposed test that uses the sentinel detection mechanism This proposed test that uses the sentinel detection mechanism
described in this document is based on the use of three DNS names described in this document is based on the use of three DNS names
that have three distinct DNS resolution behaviours. The test is that have three distinct DNS resolution behaviours. The test is
intended to allow a user or a third party to determine the state of intended to allow a user or a third party to determine the state of
their DNS resolution system, and, in particular, whether or not they their DNS resolution system, and, in particular, whether or not they
are using validating DNS resolvers that use a particular trust anchor are using validating DNS resolvers that use a particular trust anchor
for the root zone. for the root zone.
skipping to change at page 12, line 18 skipping to change at page 12, line 18
Wessels for providing comments in the form of a pull request. Petr Wessels for providing comments in the form of a pull request. Petr
Specek implmented early versions of this technique into the Knot Specek implmented early versions of this technique into the Knot
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
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 -05 to -06:
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
maximally readable.
From -04 to -05: From -04 to -05:
o Incorporated Duane's #10 o Incorporated Duane's #10
o Integrated Petr Spacek's Issue - https://github.com/APNIC-Labs/ o Integrated Petr Spacek's Issue - https://github.com/APNIC-Labs/
draft-kskroll-sentinel/issues/9 (note that commit-log incorrectly draft-kskroll-sentinel/issues/9 (note that commit-log incorrectly
referred to Duane's PR as number 9, it is actually 10). referred to Duane's PR as number 9, it is actually 10).
From -03 to -04: From -03 to -04:
skipping to change at page 14, line 9 skipping to change at page 14, line 19
[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>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013, <https://www.rfc-
editor.org/info/rfc6840>.
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)", RFC
8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc- 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-
editor.org/info/rfc8145>. editor.org/info/rfc8145>.
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
 End of changes. 16 change blocks. 
42 lines changed or deleted 44 lines changed or added

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