draft-huston-kskroll-sentinel-02.txt   draft-huston-kskroll-sentinel-03.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 29, 2018 W. Kumari Expires: May 18, 2018 W. Kumari
Google Google
October 26, 2017 November 14, 2017
A Sentinel for Detecting Trusted Keys in DNSSEC A Sentinel for Detecting Trusted Keys in DNSSEC
draft-huston-kskroll-sentinel-02.txt draft-huston-kskroll-sentinel-03.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 1, line 38 skipping to change at page 1, line 38
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 https://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 April 29, 2018. This Internet-Draft will expire on May 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(https://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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
(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 original query contains exactly the response is authentic, and if the left-most label of the original
one label that 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 original query contains exactly the response is authentic, and if the left-most label of the qriginal
one label that 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 5, line 4 skipping to change at page 5, line 4
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
respond with an A record response for "is-ta", SERVFAIL for "not- respond with an A record response for "_is-ta", SERVFAIL for
ta" and SERVFAIL for the invalid name. "_not-ta" and SERVFAIL for the invalid name.
o Vold: A DNSSEC-Validating resolver that includes this mechanism o Vold: A DNSSEC-Validating resolver that includes this mechanism
that has not loaded the nominated key into its trusted key stash that has not loaded the nominated key into its trusted key stash
will respond with an SERVFAIL record for "is-ta", an A record will respond with an SERVFAIL record for "_is-ta", an A record
response for "not-ta" and SERVFAIL for the invalid name. response for "_not-ta" and SERVFAIL for the invalid name.
o Vleg: A DNSSEC-Validating resolver that does not include this o Vleg: A DNSSEC-Validating resolver that does not include this
mechanism will respond with an A record response for "is-ta", an A mechanism will respond with an A record response for "_is-ta", an
record response for "not-ta" and SERVFAIL for the invalid name. A record response for "_not-ta" and SERVFAIL for the invalid name.
o nonV: A non-DNSSEC-Validating resolver will respond with an A o nonV: A non-DNSSEC-Validating resolver will respond with an A
record response for "is-ta", an A record response for "not-ta" and record response for "_is-ta", an A record response for "_not-ta"
an A record response for the invalid name. and an A record 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 loaded a particular key into its local trusted whether or not it has loaded a particular key into its local trusted
key stash. key stash.
+-------------+----------+-----------+------------+ +-------------+----------+-----------+------------+
| Type\Query | is_ta | not_ta | invalid | | Type\Query | _is-ta | _not-ta | invalid |
+-------------+----------+-----------+------------+ +-------------+----------+-----------+------------+
| Vnew | A | SERVFAIL | SERVFAIL | | Vnew | A | SERVFAIL | SERVFAIL |
| Vold | SERVFAIL | A | SERVFAIL | | Vold | SERVFAIL | A | SERVFAIL |
| Vleg | A | A | SERVFAIL | | Vleg | A | A | SERVFAIL |
| nonV | A | A | A | | nonV | A | A | A |
+-------------+----------+-----------+------------+ +-------------+----------+-----------+------------+
A Vnew response pattern says that the nominated key is trusted by the A Vnew response pattern says that the nominated key is trusted by the
resolver and has been loaded into its local trusted key stash. A resolver and has been loaded into its local trusted key stash. A
Vleg response pattern says that the nominated key is not yet trusted Vleg response pattern says that the nominated key is not yet trusted
 End of changes. 11 change blocks. 
17 lines changed or deleted 17 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/