< draft-bretelle-dprive-dot-for-insecure-delegations-00.txt   draft-bretelle-dprive-dot-for-insecure-delegations-01.txt >
Network Working Group M. Bretelle Network Working Group M. Bretelle
Internet-Draft Facebook Internet-Draft Facebook
Intended status: Standards Track September 27, 2018 Intended status: Standards Track March 11, 2019
Expires: March 31, 2019 Expires: September 12, 2019
DNS-over-TLS for insecure delegations DNS-over-TLS for insecure delegations
draft-bretelle-dprive-dot-for-insecure-delegations-00 draft-bretelle-dprive-dot-for-insecure-delegations-01
Abstract Abstract
This document describes an alternate mechanism to DANE ([RFC6698]) in This document describes an alternative mechanism to DANE ([RFC6698])
order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative
server by not making DNSSEC a hard requirement, making DoT server server by not making DNSSEC a hard requirement, making DoT server
authentication available for insecure delegations. authentication available for insecure delegations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 31, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Authenticating an insecure delegation . . . . . . . . . . . . 3 3. Authenticating an insecure delegation . . . . . . . . . . . . 3
3.1. Public Key Infranstructure (PKIX) . . . . . . . . . . . . 3 3.1. Public Key Infrastructure (PKIX) . . . . . . . . . . . . 3
3.2. Simple Public-Key Infrastructure (SPKI) . . . . . . . . . 3 3.2. Subject Public Key Info (SPKI) . . . . . . . . . . . . . 3
3.3. Authenticating from the parent . . . . . . . . . . . . . 4 3.3. Authenticating from the parent . . . . . . . . . . . . . 4
3.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 4 3.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 4
4. DSPKI Resource Record . . . . . . . . . . . . . . . . . . . . 5 4. DSPKI Resource Record . . . . . . . . . . . . . . . . . . . . 4
4.1. DSPKI RDATA Format . . . . . . . . . . . . . . . . . . . 5 4.1. The DSPKI Resource Record . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4.1.1. DSPKI RDATA Wire Format . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
This document describes an alternate mechanism to [RFC6698] as This document describes an alternative mechanism to DANE ([RFC6698])
described in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2 as described in [I-D.bortzmeyer-dprive-resolver-to-auth] Section 2
extending the authentication of DoT [RFC7858] to insecure delegations extending the authentication of DNS over Transport Layer Security
and therefore enabling the onboarding of DoT authoritative servers (DoT) [RFC7858] to insecure delegations and therefore enabling the
without the requirement for the authorities to support DNSSEC onboarding of DoT authoritative servers without the requirement for
([RFC4033], [RFC4034], and [RFC4035]). To do so, this document the authorities to support DNSSEC ([RFC4033], [RFC4034], and
introduce the Delegation SPKI (DSPKI) resource record, its purpose, [RFC4035]). To do so, this document introduce the Delegation Subject
usage and format. Public Key Info (DSPKI) resource record, its purpose, usage and
format.
2. Terminology 2. Terminology
A server that supports DNS-over-TLS is called a "DoT server" to A server that supports DNS-over-TLS is called a "DoT server" to
differentiate it from a "DNS Server" (one that provides DNS service differentiate it from a "DNS Server" (one that provides DNS service
over any other protocol), likewise, a client that supports this over any other protocol), likewise, a client that supports this
protocol is called a "DoT client" protocol is called a "DoT client"
A secure delegation ([RFC4956] Section 2) is a signed name containing A secure delegation ([RFC4956] Section 2) is a signed name containing
a delegation (NS RRset), and a signed DS RRset, signifying a a delegation (NS RRset), and a signed DS RRset, signifying a
skipping to change at page 3, line 20 skipping to change at page 3, line 22
this method is valid, the absence of support of DNSSEC for such this method is valid, the absence of support of DNSSEC for such
delegations precludes the onboarding and discovery of nameservers delegations precludes the onboarding and discovery of nameservers
serving those zones as DoT servers. serving those zones as DoT servers.
Without the use of DNSSEC, a delegation is not able to authenticate Without the use of DNSSEC, a delegation is not able to authenticate
itself as the chain of trust cannot be followed, however other itself as the chain of trust cannot be followed, however other
mechanisms exist to have a server authenticate itself, such as Public mechanisms exist to have a server authenticate itself, such as Public
Key Infrastructure (PKIX [RFC6125]) , SPKI, which have their own pros Key Infrastructure (PKIX [RFC6125]) , SPKI, which have their own pros
and cons. and cons.
3.1. Public Key Infranstructure (PKIX) 3.1. Public Key Infrastructure (PKIX)
It would be possible to authenticate the nameservers of the insecure It would be possible to authenticate the name servers of the insecure
delegation using PKIX, relying on an existing trust model and trust delegation using PKIX, relying on an existing trust model and trust
anchors. anchors.
While simple, a single trusted CA that breaks said trust (voluntarily While simple, a single trusted Certificate Authority (CA) that breaks
or involuntarily), can issue certificate for any domains, allowing an said trust (voluntarily or involuntarily), can issue certificate for
attacker to potentially impersonate both the application and the DoT any domains, allowing an attacker to potentially impersonate both the
server. application and the DoT server.
Another issue that rises is that the DoT servers may use an identity Another issue that rises is that the DoT servers may use an identity
which belong to the same origin as application servers, which could which belong to the same origin as application servers, which could
permit personal information (such as cookies) to be leaked to the DoT permit personal information (such as cookies) to be leaked to the DoT
servers. servers.
3.2. Simple Public-Key Infrastructure (SPKI) 3.2. Subject Public Key Info (SPKI)
SPKI on the other hand does not have the same issues than PKIX, the
certificates can be generated by the authority itself, adding a
separation of privileges between the PKIX infrastructure and the DNS
one.
The problem is now on how to advertise/distribute the delegation's The zone owner generates his own certificate and distribute the SPKI
public key. fingerprint into the DNS.
This is in essence what TLSA records solve, but with the use of This is in essence what, amongst other things, TLSA records solve but
DNSSEC enabled and functional for the queried zone. For insecure with the requirement for DNSSEC to be enabled and functional for the
delegations, simply advertising the public key would be subject to queried zone. For insecure delegations, simply advertising the SPKI
interception and mangling. fingerprint would be trivial to intercept, disable, and modify.
3.3. Authenticating from the parent 3.3. Authenticating from the parent
While a delegation is not secured, the DNS core infrastructure While a delegation is not secured, the DNS core infrastructure
already support DNSSEC, meaning that if the owner of an insecure already support, for the most part, DNSSEC, meaning that if the owner
delegation could set the public key to authenticate the DoT servers of an insecure delegation could set the SPKI fingerprint in a
against, such key could be authenticated using DNSSEC at the parent resource record (RR) at the parent, such fingerprint could be signed
level, which would then permit trusting the DoT servers providing and validated by the DoT client. The DoT client can then establish a
their certificate validates against the ( then validated) public key TLS connection to the zone name servers and authenticate the DoT
provided by the parent. server against the fingerprint acquired earlier from the parent zone.
From this stage, the "formerly" insecure delegation can be
authenticated, and therefore considered secure, allowing delegating
to other zones which can be authenticated by either DNSSEC or TLS.
In order to provide its public key to the DoT clients, an insecure
would set the DSPKI RRset at the parent with the content of its
extracted SPKI, which the parent then sign.
A DoT client which is about to talk with a DoT server can obtain and
validate the DSPKI RRset from the parent and authenticate the DoT
server, without needing the DoT server to serve a secure delegation.
3.3.1. Example 3.3.1. Example
example.com is an insecure delegation from .com which has set the example.com is an insecure delegation from .com which has set the
DSPKI RRset. DSPKI RRset.
A DoT client looking for records under example.com will learn from A DoT client looking for records under example.com will learn from
.com that example.com is delegated to .com that example.com is delegated to
example.com 172800 NS ns1.example.com example.com IN 172800 NS ns1.example.com
example.com 172800 NS ns2.example.com example.com IN 172800 NS ns2.example.com
example.com 86400 DSPKI h0KPxSKAPTEGXnvOPPA/5HUJZjHl4Hu9eg/eYMTPJcc= # sha256
ns1.example.com 172800 AAAA 2001:db8:abcd:12:1:2:3:4 example.com IN DSPKI (
ns2.example.com 172800 AAAA 2001:db8:abcd:ab:1:2:3:4 1 4e44f900cdeb8c769f4df97e23f8fc81
4ac4bf45a3d9dc265a2ed925171f0b71 )
# sha512
example.com IN DSPKI (
2 ab40ed300fd220d8c72a600069f9ceb1
f9fd7c003117e4ef34b228da1c9d76a0
500be99e82a0c01e7f80930a46ad28b8
ed3d5ed2df34d822b5f56c99f45889ef
)
ns1.example.com IN 172800 AAAA 2001:db8:abcd:12:1:2:3:4
ns2.example.com IN 172800 AAAA 2001:db8:abcd:ab:1:2:3:4
with the accompanying signature. with the accompanying signature.
The DSPKI RRset signals that the nameservers are able to support DNS- The DSPKI RRset signals that the nameservers are able to support DNS-
over-TLS and the DoT client can authenticate them using the provided over-TLS. The DoT client can then establish a TLS connection to the
public key, DoT server and authenticate them by ensuring that the SPKI matches
the one learned from the parent zone.
If subzone.example.com is a delegation from example.com, example.com
can provide the DSPKI RRSet of the delegation. While example.com is
not a secured delegation, because it has been authenticated using
TLS, it is also able to be part of the chain of trust and provide
either a DS or DSPKI RRset for subzone.example.com
4. DSPKI Resource Record 4. DSPKI Resource Record
There may be 0 or more DSPKI served by the parent of the delegation. There may be 0 or more DSPKI served by the parent of the delegation.
0 would mean that DSPKI is not supported, therefore the DoT client 0 means that DSPKI is not supported, therefore the DoT client could
could try other alternatives. 1 or multiple public keys can be try other alternatives. 1 or multiple public keys can be distributed
distributed to let the DoT client validate multiple public keys, to let the DoT client validate multiple public keys, which can be
which can be useful while doing certificate rotation or when willing useful while doing certificate rotation or when willing to provide
to provide different secret keys to different providers that may different secret keys to different providers that may serve the
serve the delegated zone. delegated zone.
4.1. DSPKI RDATA Format 4.1. The DSPKI Resource Record
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The DSPKI resource record (RR) is used to associate a DoT server
/ PUBKEY / public key (SPKI) with the zone it is serving.
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where PUBKEY: A base64 encoded string of the sha256sum of the public 4.1.1. DSPKI RDATA Wire Format
key, as generated by: ~~~~ openssl x509 -in cert.pem -pubkey -noout |
openssl pkey -pubin -outform der | \ openssl dgst -sha256 -binary |
openssl enc -base64 ~~~~
*FIXME*: consider * format that can evolve over time, e.g 1 byte The RDATA of the DSPKI RR consists of a one-octet matching type
specifying hashing algorithm. * no need for base64, raw bytes are field, and the DER-encoded binary structure of the
fine. * alternate URI to support DoT (host, port, spki), DoH (host, SubjectPublicKeyInfo field as defined in [RFC5280].
port, URL template), DNS-over-QUIC... would rather be an ALTNS type
of record * CDSPKI a la CDS, CDNSKEY 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| matching type | DER-encoded SPKI field /
+-+-+-+-+-+-+-+-+ /
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1.1. The Matching Type Field
A one-octet value, called "matching type", specifies how the SPKI is
presented. The types defined in this document are:
o 0 - Exact match on SPKI
o 1 - SHA-256 hash of SPKI
o 2 - SHA-512 hash of SPKI
Where the SPKI can be extracted as follow:
openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform der
and the SHA-256 as:
openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform der | \
openssl dgst -sha256 -binary
*FIXME*: consider
o alternate URI to support DoT (host, port, spki), DoH (host, port,
URL template), DNS-over-QUIC... would rather be an ALTNS type of
record
o CDSPKI a la CDS, CDNSKEY
5. Security Considerations 5. Security Considerations
TODO Security TODO Security
6. IANA Considerations 6. IANA Considerations
TODO: This document requires IANA actions (new RR type). TODO: This document requires IANA actions (new RR type).
7. Normative References 7. Normative References
skipping to change at page 6, line 24 skipping to change at page 6, line 47
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
(DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
2007, <https://www.rfc-editor.org/info/rfc4956>. 2007, <https://www.rfc-editor.org/info/rfc4956>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
 End of changes. 23 change blocks. 
91 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/