< draft-ghedini-dprive-early-data-00.txt   draft-ghedini-dprive-early-data-01.txt >
Network Working Group A. Ghedini Network Working Group A. Ghedini
Internet-Draft Cloudflare, Inc. Internet-Draft Cloudflare, Inc.
Intended status: Standards Track March 25, 2019 Intended status: Standards Track July 06, 2019
Expires: September 26, 2019 Expires: January 7, 2020
Using Early Data in DNS over TLS Using Early Data in DNS over TLS
draft-ghedini-dprive-early-data-00 draft-ghedini-dprive-early-data-01
Abstract Abstract
This document illustrates the risks of using TLS 1.3 early data with This document illustrates the risks of using TLS 1.3 early data with
DNS over TLS, and specifies behaviors that can be adopted by clients DNS over TLS, and specifies behaviors that can be adopted by clients
and servers to reduce those risks. and servers to reduce those risks.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 September 26, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
3. Early Data in DNS over TLS . . . . . . . . . . . . . . . . . 3 3. Early Data in DNS over TLS . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4.1. Information Exposure . . . . . . . . . . . . . . . . . . 3 4.1. Information Exposure . . . . . . . . . . . . . . . . . . 3
4.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 4 4.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 4
4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
TLS 1.3 [TLS13] defines a mechanism, called 0-RTT session resumption TLS 1.3 [TLS13] defines a mechanism, called 0-RTT session resumption
or early data, that allows clients to send data to servers in the or early data, that allows clients to send data to servers in the
first round-trip of a connection without having to wait for the TLS first round-trip of a resumed connection without having to wait for
handshake to complete. the TLS handshake to complete.
This can be used to send DNS queries to DNS over TLS [DOT] servers This can be used to send DNS queries to DNS over TLS [DOT] servers
without incurring in the cost of the additional round-trip required without incurring in the cost of the additional round-trip required
by the TLS handshake, and it can be useful in cases where new DNS by the TLS handshake. This can provide significant performance
over TLS connections need to be established often such as on mobile improvements in cases where new DNS over TLS connections need to be
clients where the network might not be stable, or on resolvers where established often such as on mobile clients where the network might
keeping an open connection to many authoritative servers might not be not be stable, or on resolvers where keeping an open connection to
practical. many authoritative servers might not be practical.
However, the use of early data allows an attacker to capture and However the use of early data allows an attacker to capture and
replay the encrypted DNS queries carried on the TLS connection. This replay the encrypted DNS queries carried on the TLS connection. This
can have unwanted consequences and help in recovering information can have unwanted consequences and help in recovering information
about those queries. While [TLS13] describes tecniques to reduce the about those queries. While [TLS13] describes tecniques to reduce the
likelihood of a replay attack, they are not perfect and still leave likelihood of a replay attack, they are not perfect and still leave
some potential for exploitation. some potential for exploitation.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Early Data in DNS over TLS 3. Early Data in DNS over TLS
TODO: talk more about 0-RTT vs. 1-RTT security properties. Early data forms a single stream of data along with other application
data, meaning that one or more DNS queries can either be partially or
fully contained within early data. Once the TLS handshake has
completed, the early data is known to not be a replayed copy of that
data, but this doesn't mean that it can't be replayed, or that it
hasn't already been replayed, in another connection.
A server can signal to clients whether it is willing to accept early A server can signal to clients whether it is willing to accept early
data in future connections by providing the "early_data" TLS data in future connections by providing the "early_data" TLS
extension as part of a TLS session ticket, as well as limit the extension as part of a TLS session ticket, as well as limit the
amount of early data it is willing to accept using the amount of early data it is willing to accept using the
"max_early_data_size" field of the "early_data" extension. "max_early_data_size" field of the "early_data" extension.
In addition to the mitigation mechanisms mandated in [TLS13] that In addition to the mitigation mechanisms mandated in [TLS13] that
reduce the ability of an attacker to replay early data, but may not reduce the ability of an attacker to replay early data, but may not
completely eliminate it, a server that decided to offer early data to completely eliminate it, a server that decided to offer early data to
clients MAY reject early data at the TLS layer, or delay the clients MAY reject early data at the TLS layer, or delay the
processing of early data to after the handshake is completed. processing of early data after the handshake is completed.
If the server rejects early data at the TLS layer, a client MUST If the server rejects early data at the TLS layer, a client MUST
forget information it optmisitically assumed about the onnection when forget information it optmisitically assumed about the onnection when
sending early data, such as the negotiated protocol [ALPN]. Any DNS sending early data, such as the negotiated protocol [ALPN]. Any DNS
queries sent in early data will need to be sent again, unless the queries sent in early data will need to be sent again, unless the
client decides to abandon them. client decides to abandon them.
TODO: forbid sending DNS updates in early data (RFC2136)? XFR? Not all types of DNS queries are safe to be sent as early data.
Other query types? Clients MUST NOT use early data to send DNS Updates ([RFC2136]) or
Zone Transfers ([RFC5936]) messages. Servers receiving any of those
messages MUST reply with a "FormErr" response code.
[[TODO: forbid other types? use a different status code? should we
define a whitelist instead of a blacklist?]]
4. Security Considerations 4. Security Considerations
4.1. Information Exposure 4.1. Information Exposure
By replaying DNS queries that were captured when transmitted over By replaying DNS queries that were captured when transmitted over
early data, an attacker might be able to expose information about early data, an attacker might be able to expose information about
those queries, even if encrypted. those queries, even if encrypted.
For example, it's a common behavior for DNS servers to statefully For example, it's a common behavior for DNS servers to statefully
rotate the order of RRs when replying to DNS queries for an RRSet rotate the order of RRs when replying to DNS queries for an RRSet
that contains multiple RRs. If the order of rotation is predictable, that contains multiple RRs. If the order of rotation is predictable,
replaying a captured early data DNS query and observing the order of replaying a captured early data DNS query and observing the order of
RRs in DNS responses before and after the replayed query, might allow RRs in DNS responses before and after the replayed query, might allow
an attacker to confirm whether the replayed query targeted a specific the attacker to confirm whether the query targeted a specific name
name that was suspected of being queried without having to decrypt that was suspected of being queried.
it.
Servers SHOULD either use fixed ordering for multiple RRs in the same Servers SHOULD either use fixed ordering for multiple RRs in the same
DNS response or shuffle the RRs at random, but MUST NOT use stateful DNS response or shuffle the RRs at random, but MUST NOT use stateful
and deterministic ordering across multiple queries. and deterministic ordering across multiple queries.
4.2. Denial of Service 4.2. Denial of Service
Accepting early data exposes a server to potential denial of service Accepting early data exposes a server to potential denial of service
through the replay of queries that might be expensive to handle. through the replay of queries that might be expensive to handle.
When under load, a server MAY reject TLS early data such that the When under load, a server MAY reject TLS early data such that the
client is forced to retry them after the handshake is completed. client is forced to retry them after the handshake is completed.
4.3. Privacy 4.3. Privacy
TODO: linkability (e.g. clients changing network, ...) and more? TBD
4.4. Acknowledgments [[TODO: linkability (e.g. clients changing network, ...) and more?]]
This document was heavily inspired by [RFC8470]. Daniel Kahn Gillmor 5. IANA Considerations
and Colm MacCarthaigh also provided important ideas and
contributions.
5. References This document has no actions for IANA.
5.1. Normative References 6. Acknowledgments
Thanks to Martin Thomson, Mark Nottingham and Willy Tarreau for
writing [RFC8470] which heavily inspired this document, and to Daniel
Kahn Gillmor and Colm MacCarthaigh who also provided important ideas
and contributions.
7. References
7.1. Normative References
[DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
5.2. Informative References 7.2. Informative References
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
Author's Address Author's Address
Alessandro Ghedini Alessandro Ghedini
Cloudflare, Inc. Cloudflare, Inc.
Email: alessandro@cloudflare.com Email: alessandro@cloudflare.com
 End of changes. 18 change blocks. 
31 lines changed or deleted 57 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/