draft-huston-kskroll-sentinel-03.txt   draft-huston-kskroll-sentinel-04.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: May 18, 2018 W. Kumari Expires: May 18, 2018 W. Kumari
Google Google
November 14, 2017 November 14, 2017
A Sentinel for Detecting Trusted Keys in DNSSEC A Sentinel for Detecting Trusted Keys in DNSSEC
draft-huston-kskroll-sentinel-03.txt draft-huston-kskroll-sentinel-04.txt
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 to determine the trusted key state of the will allow an end user to determine the trusted key state of the
resolvers that handle the user's DNS queries. resolvers that handle the user's DNS queries.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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. Sentinel Mechanism 2. Sentinel Mechanism
DNSSEC-Validating resolvers that implement this mechanism MUST be DNSSEC-Validating resolvers that implement this mechanism MUST be
performing validation of responses in accordance with the DNSSEC performing validation of responses in accordance with the DNSSEC
response validation specification [RFC4035]. response validation specification [RFC4035].
This mechanism makes use of 2 special labels, "._is-ta-<tag-index>." This mechanism makes use of 2 special labels, "_is-ta-<tag-index>."
(Intended to be used in a query where the response can answer the (Intended to be used in a query where the response can answer the
question: Is this the key tag a trust anchor which the validating DNS question: Is this the key tag a trust anchor which the validating DNS
resolver is currently trusting?) and "._not-ta-<tag-index>." resolver is currently trusting?) and "_not-ta-<tag-index>."
(Intended to be used in a query where the response can answer the (Intended to be used in a query where the response can answer the
question: Is this the key tag of a key that is NOT in the resolver's question: Is this the key tag of a key that is NOT in the resolver's
current trust store?). The use of the positive question and its current trust store?). The use of the positive question and its
inverse allows for queries to detect whether resolvers support this inverse allows for queries to detect whether resolvers support this
mechanism. mechanism.
If the outcome of the DNS response validation process indicates that If the outcome of the DNS response validation process indicates that
the response is authentic, and if the left-most label of the original the response is authentic, and if the left-most label of the original
query name matches the template "._is-ta-<tag-index>.", then the query name matches the template "_is-ta-<tag-index>.", then the
following rule should be applied to the response: If the resolver has following rule should be applied to the response: If the resolver has
placed a Root Zone Key Signing Key with tag index value matching the placed a Root Zone Key Signing Key with tag index value matching the
value specified in the query into the local resolver's store of value specified in the query into the local resolver's store of
trusted keys, then the resolver should return a response indicating trusted keys, then the resolver should return a response indicating
that the response contains authenticated data according to section that the response contains authenticated data according to section
5.8 of [RFC6840]. Otherwise, the resolver MUST return RCODE 2 5.8 of [RFC6840]. Otherwise, the resolver MUST return RCODE 2
(server failure). Note that the <tag-index> is specified in the DNS (server failure). Note that the <tag-index> is specified in the DNS
label using hex notation. label using hex notation.
If the outcome of the DNS response validation process indicates that If the outcome of the DNS response validation process indicates that
the response is authentic, and if the left-most label of the qriginal the response is authentic, and if the left-most label of the qriginal
query name matches the template "._not-ta-<tag-index>.", then the query name matches the template "_not-ta-<tag-index>.", then the
following rule should be applied to the response: If the resolver has following rule should be applied to the response: If the resolver has
not placed a Root Zone Key Signing Key with tag index value matching not placed a Root Zone Key Signing Key with tag index value matching
the value specified in the query into the local resolver's store of the value specified in the query into the local resolver's store of
trusted keys, then the resolver should return a response indicating trusted keys, then the resolver should return a response indicating
that the response contains authenticated data according to section that the response contains authenticated data according to section
5.8 of [RFC6840]. Otherwise, the resolver MUST return RCODE 2 5.8 of [RFC6840]. Otherwise, the resolver MUST return RCODE 2
(server failure). Note that the <tag-index> is specified in the DNS (server failure). Note that the <tag-index> is specified in the DNS
label using hex notation. label using hex notation.
If a query contains one instance of both of these query templates If a query contains one instance of both of these query templates
skipping to change at page 4, line 36 skipping to change at page 4, line 36
that have picked up an incoming trust anchor in a key roll. that have picked up an incoming trust anchor in a key roll.
The name format can be defined in a number of ways, and no name form The name format can be defined in a number of ways, and no name form
is intrinsically better than any other in terms of the test itself. is intrinsically better than any other in terms of the test itself.
The critical aspect of the DNS names used in any such test is that The critical aspect of the DNS names used in any such test 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. test.
The sentinel process is envisaged to use a test with three names: The sentinel process is envisaged to use a test with three names:
a. a name containing the label "._is-ta-<tag-index>.". This is a a. a name containing the left-most label "_is-ta-<tag-index>.".
validly signed name so that responses about names in this zone This is a validly signed name so that responses about names in
can be authenticated by a validating resolver. this zone can be authenticated by a validating resolver.
b. a name containing the label "._not-ta-<tag-index>.". This is b. a name containing the left-most label "_not-ta-<tag-index>.".
also a validly-signed name. This is also a validly-signed name.
c. a third name that is signed with a DNSSEC signature that cannot c. a third name that is signed with a DNSSEC signature that cannot
be validated. be validated.
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. environment.
o Vnew: A DNSSEC-Validating resolver that includes this mechanism o Vnew: A DNSSEC-Validating resolver that includes this mechanism
that has loaded the nominated key into its trusted key stash will that has loaded the nominated key into its trusted key stash will
 End of changes. 7 change blocks. 
10 lines changed or deleted 10 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/