< draft-ietf-dnsop-kskroll-sentinel-10.txt   draft-ietf-dnsop-kskroll-sentinel-11.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: October 5, 2018 W. Kumari Expires: October 7, 2018 W. Kumari
Google Google
April 3, 2018 April 5, 2018
A Root Key Trust Anchor Sentinel for DNSSEC A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-10 draft-ietf-dnsop-kskroll-sentinel-11
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 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 October 5, 2018. This Internet-Draft will expire on October 7, 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
(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 2, line 45 skipping to change at page 2, line 45
4. Processing Sentinel Results . . . . . . . . . . . . . . . . . 8 4. Processing Sentinel Results . . . . . . . . . . . . . . . . . 8
5. Sentinel Test Result Considerations . . . . . . . . . . . . . 10 5. Sentinel Test Result Considerations . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and
[RFC4035] were developed to provide origin authentication and [RFC4035] were developed to provide origin authentication and
integrity protection for DNS data by using digital signatures. integrity protection for DNS data by using digital signatures.
DNSSEC uses Key Tags to efficiently match signatures to the keys from DNSSEC uses Key Tags to efficiently match signatures to the keys from
which they are generated. The Key Tag is a 16-bit value computed which they are generated. The Key Tag is a 16-bit value computed
from the RDATA portion of a DNSKEY RR using a formula similar to a from the RDATA portion of a DNSKEY RR using a formula similar to a
ones-complement checksum. RRSIG RRs contain a Key Tag field whose ones-complement checksum. RRSIG RRs contain a Key Tag field whose
skipping to change at page 7, line 36 skipping to change at page 7, line 36
is currently trusting?" Labels containing "root-key-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 o The DNS response is DNSSEC validated.
o the result of validation is "Secure" o The result of validation is "Secure".
o the AD bit is to be set in the response o The Checking Disabled (CD) bit in the query is not set.
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 original QNAME (the name sent in the o The leftmost label of the original QNAME (the name sent in the
Question Section in the orignal query) is either "root-key- Question Section in the original query) is either "root-key-
sentinel-is-ta-<key-tag>" or "root-key-sentinel-not-ta-<key-tag>" sentinel-is-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.
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 -10 to -11:
o Clarified the preconditions for this mechanism as per Working
Group mailing list discussion.
o Corrected minor typo.
From -09 to -10: From -09 to -10:
o Clarified the precondition list to specify that the resolver had o Clarified the precondition list to specify that the resolver had
performed DNSSEC-validation by setting the AD bit in the response performed DNSSEC-validation by setting the AD bit in the response
o Clarified the language referring to the operation of RFC8145 o Clarified the language referring to the operation of RFC8145
signalling. signalling.
From -08 to -09: From -08 to -09:
 End of changes. 10 change blocks. 
9 lines changed or deleted 16 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/