< draft-ietf-dnsop-kskroll-sentinel-13.txt   draft-ietf-dnsop-kskroll-sentinel-14.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: December 6, 2018 W. Kumari Expires: December 13, 2018 W. Kumari
Google Google
June 4, 2018 June 11, 2018
A Root Key Trust Anchor Sentinel for DNSSEC A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-13 draft-ietf-dnsop-kskroll-sentinel-14
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 1, line 46 skipping to change at page 1, line 46
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 December 6, 2018. This Internet-Draft will expire on December 13, 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 38 skipping to change at page 2, line 38
3.1. Forwarders . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Forwarders . . . . . . . . . . . . . . . . . . . . . . . 8
4. Sentinel Tests for a Set of Resolvers . . . . . . . . . . . . 9 4. Sentinel Tests for a Set of Resolvers . . . . . . . . . . . . 9
4.1. Test Scenario and Objective . . . . . . . . . . . . . . . 9 4.1. Test Scenario and Objective . . . . . . . . . . . . . . . 9
4.2. Test Assumptions . . . . . . . . . . . . . . . . . . . . 10 4.2. Test Assumptions . . . . . . . . . . . . . . . . . . . . 10
4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 10 4.3. Test Procedure . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
7. Implementation Experience . . . . . . . . . . . . . . . . . . 12 7. Implementation Experience . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Protocol Walkthrough Example . . . . . . . . . . . . 17 Appendix A. Protocol Walkthrough Example . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 found in "Key from the RDATA portion of a DNSKEY RR using a formula found in "Key
Tag Calculation" (Appendix B of "Resource Records for the DNS Tag Calculation" (Appendix B of "Resource Records for the DNS
skipping to change at page 10, line 4 skipping to change at page 10, line 4
when the root zone is signed with KSK-new. when the root zone is signed with KSK-new.
The objective of the test is to determine if the user will be The objective of the test is to determine if the user will be
negatively impacted by the KSK roll. A "negative impact" for the negatively impacted by the KSK roll. A "negative impact" for the
user is defined such that all the configured resolvers are security- user is defined such that all the configured resolvers are security-
aware resolvers that perform validation of DNSSEC-signed responses, aware resolvers that perform validation of DNSSEC-signed responses,
and none of these resolvers have loaded KSK-new into their local and none of these resolvers have loaded KSK-new into their local
trust anchor set. In this situation, it is anticipated that once the trust anchor set. In this situation, it is anticipated that once the
KSK is rolled the entire set of the user's resolvers will not be able KSK is rolled the entire set of the user's resolvers will not be able
to validate the contents of the root zone and the user is likely to to validate the contents of the root zone and the user is likely to
loose DNS service as a result of this inability to perform successful lose DNS service as a result of this inability to perform successful
DNSSEC validation. DNSSEC validation.
4.2. Test Assumptions 4.2. Test Assumptions
There are a number of assumptions about the DNS environment used in There are a number of assumptions about the DNS environment used in
this test. Where these assumptions do not hold, the results of the this test. Where these assumptions do not hold, the results of the
test will be indeterminate. test will be indeterminate.
o When a recursive resolver returns SERVFAIL to the user's stub o When a recursive resolver returns SERVFAIL to the user's stub
resolver, the stub resolver will send the same query to the next resolver, the stub resolver will send the same query to the next
skipping to change at page 10, line 39 skipping to change at page 10, line 39
There is no current published measurement data that indicates to what There is no current published measurement data that indicates to what
extent the first two assumptions listed here are valid, and how many extent the first two assumptions listed here are valid, and how many
end users may be impacted by these assumptions. In particular, the end users may be impacted by these assumptions. In particular, the
first assumption, that a consistent SERFAIL response will cause the first assumption, that a consistent SERFAIL response will cause the
local stub DNS resolution environment to query all of its configured local stub DNS resolution environment to query all of its configured
recursive resolvers before concluding that the name cannot be recursive resolvers before concluding that the name cannot be
resolved, is a very critical assumption for this test. resolved, is a very critical assumption for this test.
4.3. Test Procedure 4.3. Test Procedure
The sentinel detection process test a DNS resolution environment with The sentinel detection process tests a DNS resolution environment
three query names: with three query names:
o A query name that is signed with a DNSSEC signature that cannot be o A query name that is signed with a DNSSEC signature that cannot be
validated (described as a "bogus" RRset in Section 5 of [RFC4033], validated (described as a "bogus" RRset in Section 5 of [RFC4033],
when, for example, an RRset is not signed with a valid RRSIG when, for example, an RRset is not signed with a valid RRSIG
record). record).
o A query name containing the left-most label "root-key-sentinel- o A query name containing the left-most label "root-key-sentinel-
not-ta-<key-tag-of-KSK-current>". This name MUST be a validly- not-ta-<key-tag-of-KSK-current>". This name MUST be a validly-
signed. Any validly-signed DNS zone can be used for this test. signed. Any validly-signed DNS zone can be used for this test.
skipping to change at page 12, line 38 skipping to change at page 12, line 38
based advertisements or javascript in web pages), can, under certain based advertisements or javascript in web pages), can, under certain
specific circumstances that includes additional knowledge of the specific circumstances that includes additional knowledge of the
resolvers that are invoked by the user, determine which trust anchors resolvers that are invoked by the user, determine which trust anchors
are configured in these resolvers. Without this additional are configured in these resolvers. Without this additional
knowledge, the third party can infer the aggregate capabilities of knowledge, the third party can infer the aggregate capabilities of
the user's DNS resolution environment, but cannot necessarily infer the user's DNS resolution environment, but cannot necessarily infer
the trust configuration of any recursive name server. the trust configuration of any recursive name server.
7. Implementation Experience 7. Implementation Experience
Petr Spacek implemented early versions of this technique into the [ RFC Editor: Please remove before publication. As this section will
Knot resolver, and identified a number of places where it wasn't be removed, it is more conversational than would appear in a
clear, and provided very helpful text to address this. published doc. ]
Ondrej Sury of ISC has reported to the DNSOP Working Group in April List of known resolver implementations (alphabetical):
2018 that this technique was peer-reviewed and merged into BIND
master branch with the intent to backport the feature into older
release branches.
Benno Overeinder of NLnet Labs reported to the DNSOP Working Group in BIND Ondrej Sury of ISC reported to the DNSOP Working Group in
April 2018 an intention to support this technique in Unbound in the April 2018 that this technique was peer-reviewed and merged into
near future. BIND master branch with the intent to backport the feature into
older release branches. The merge request:
https://gitlab.isc.org/isc-projects/bind9/merge_requests/123
Information on configuring this can be found in the BIND 9.13.0
Administrator Reference Manual (ARM), available at
https://ftp.isc.org/isc/bind9/9.13.0/doc/arm/Bv9ARM.pdf
An implementation of the client side of this protocol is available Knot resolver Petr Spacek implemented early versions of this
at: http://www.ksk-test.net technique into the Knot resolver, identified a number of places
where it wasn't clear, and provided very helpful text to address
these issues and make the document mode clear. Petr also
identified an embarrassingly large number of typos (and similar)
in the ksk-test setup. More information is at http://knot-
resolver.readthedocs.io/en/stable/modules.html#sentinel-for-
detecting-trusted-keys
Unbound Benno Overeinder of NLnet Labs reported to the DNSOP Working
Group in April 2018 an intention to support this technique in
Unbound in the near future. This is now implemented in Unbound
version 1.7.1, available from http://unbound.nlnetlabs.nl/
download.html . Configuration information is at
http://unbound.nlnetlabs.nl/documentation/unbound.conf.html
A (partial) list of "client" / user side implementations (the author
was keeping a more complete list of implementations, but has
misplaced it - apologies, I'm happy to re-add them if you send me a
note.):
http://www.ksk-test.net An Javascript implementation of the client
side of this protocol is available at: http://www.ksk-test.net
http://test.kskroll.dnssec.lab.nic.cl/ Hugo Salgado-Hernandez has
created an implementation at
http://test.kskroll.dnssec.lab.nic.cl/
http://sentinel.research.icann.org/ The code for this implementation
is published at https://github.com/paulehoffman/sentinel-testbed
8. IANA Considerations 8. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA [Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.] considerations stated in this version of the document.]
9. Acknowledgements 9. Acknowledgements
This document has borrowed extensively from [RFC8145] for the This document has borrowed extensively from [RFC8145] for the
introductory text, and the authors would like to acknowledge and introductory text, and the authors would like to acknowledge and
thank the authors of that document both for some text excerpts and thank the authors of that document both for some text excerpts and
for the more general stimulation of thoughts about monitoring the for the more general stimulation of thoughts about monitoring the
progress of a roll of the KSK of the root zone of the DNS. progress of a roll of the KSK of the root zone of the DNS.
The authors would like to thank Joe Abley, Mehmet Akcin, Mark The authors would like to thank Joe Abley, Mehmet Akcin, Mark
Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David Andrews, Richard Barnes, Ray Bellis, Stephane Bortzmeyer, David
Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes Conrad, Ralph Dolmans, John Dickinson, Steinar Haug, Bob Harold, Wes
Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis, Hardaker, Paul Hoffman, Matt Larson, Jinmei Tatuya, Edward Lewis,
George Michaelson, Benno Overeinder, Matthew Pounsett, Andreas George Michaelson, Benno Overeinder, Matthew Pounsett, Hugo Salgado-
Schulze, Mukund Sivaraman, Petr Spacek, Job Snijders, Andrew Hernandez, Andreas Schulze, Mukund Sivaraman, Petr Spacek, Job
Sullivan, Ondrej Sury, Paul Vixie, Duane Wessels and Paul Wouters for Snijders, Andrew Sullivan, Ondrej Sury, Paul Vixie, Duane Wessels and
their helpful feedback. Paul Wouters for their helpful feedback.
The authors would like to especially call out Paul Hoffman and Duane The authors would like to especially call out Paul Hoffman and Duane
Wessels for providing comments in the form of a pull request. Wessels for providing comments in the form of a pull request.
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 -13 to -14:
o Addressed nits from Bob Harold -
https://mailarchive.ietf.org/arch/msg/dnsop/
j4Serw0z24o470AnlD8ISo8o9k4
o Formatting changes (and a bit more text) in the implementation
section.
o Closes PR #21: Clarify indeterminate and resolution systems,
o Closes PR #22: Updates to -13 describing the test procedure for a
set of resolvers
o Closes PR #23: Fix sundry typos,
o Closes PR #24: Editorial and clarifications to the new text
o Closes PR #25: Clarified when the test can be run
From -12 to -13: From -12 to -13:
o Merged Paul Hoffmans PR#19, PR#20. o Merged Paul Hoffmans PR#19, PR#20.
o Moved toy ksk-test.net to implmentation section. o Moved toy ksk-test.net to implementation section.
o Split the test procedures between the test of a single DNS o Split the test procedures between the test of a single DNS
resolvers and the test of a collection of DNS resolvers as would resolvers and the test of a collection of DNS resolvers as would
be found in an end user environment. be found in an end user environment.
From -11 to -12: From -11 to -12:
o Moved the Walkthrough Example to the end of the document as an o Moved the Walkthrough Example to the end of the document as an
appendix. appendix.
 End of changes. 14 change blocks. 
30 lines changed or deleted 80 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/