| < 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 | |||
| 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||