idnits 2.17.1 draft-ghedini-dprive-early-data-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ghedini 3 Internet-Draft Cloudflare, Inc. 4 Intended status: Standards Track July 06, 2019 5 Expires: January 7, 2020 7 Using Early Data in DNS over TLS 8 draft-ghedini-dprive-early-data-01 10 Abstract 12 This document illustrates the risks of using TLS 1.3 early data with 13 DNS over TLS, and specifies behaviors that can be adopted by clients 14 and servers to reduce those risks. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 7, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 52 3. Early Data in DNS over TLS . . . . . . . . . . . . . . . . . 3 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 4.1. Information Exposure . . . . . . . . . . . . . . . . . . 3 55 4.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 4 56 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 7.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 TLS 1.3 [TLS13] defines a mechanism, called 0-RTT session resumption 67 or early data, that allows clients to send data to servers in the 68 first round-trip of a resumed connection without having to wait for 69 the TLS handshake to complete. 71 This can be used to send DNS queries to DNS over TLS [DOT] servers 72 without incurring in the cost of the additional round-trip required 73 by the TLS handshake. This can provide significant performance 74 improvements in cases where new DNS over TLS connections need to be 75 established often such as on mobile clients where the network might 76 not be stable, or on resolvers where keeping an open connection to 77 many authoritative servers might not be practical. 79 However the use of early data allows an attacker to capture and 80 replay the encrypted DNS queries carried on the TLS connection. This 81 can have unwanted consequences and help in recovering information 82 about those queries. While [TLS13] describes tecniques to reduce the 83 likelihood of a replay attack, they are not perfect and still leave 84 some potential for exploitation. 86 2. Notational Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 3. Early Data in DNS over TLS 96 Early data forms a single stream of data along with other application 97 data, meaning that one or more DNS queries can either be partially or 98 fully contained within early data. Once the TLS handshake has 99 completed, the early data is known to not be a replayed copy of that 100 data, but this doesn't mean that it can't be replayed, or that it 101 hasn't already been replayed, in another connection. 103 A server can signal to clients whether it is willing to accept early 104 data in future connections by providing the "early_data" TLS 105 extension as part of a TLS session ticket, as well as limit the 106 amount of early data it is willing to accept using the 107 "max_early_data_size" field of the "early_data" extension. 109 In addition to the mitigation mechanisms mandated in [TLS13] that 110 reduce the ability of an attacker to replay early data, but may not 111 completely eliminate it, a server that decided to offer early data to 112 clients MAY reject early data at the TLS layer, or delay the 113 processing of early data after the handshake is completed. 115 If the server rejects early data at the TLS layer, a client MUST 116 forget information it optmisitically assumed about the onnection when 117 sending early data, such as the negotiated protocol [ALPN]. Any DNS 118 queries sent in early data will need to be sent again, unless the 119 client decides to abandon them. 121 Not all types of DNS queries are safe to be sent as early data. 122 Clients MUST NOT use early data to send DNS Updates ([RFC2136]) or 123 Zone Transfers ([RFC5936]) messages. Servers receiving any of those 124 messages MUST reply with a "FormErr" response code. 126 [[TODO: forbid other types? use a different status code? should we 127 define a whitelist instead of a blacklist?]] 129 4. Security Considerations 131 4.1. Information Exposure 133 By replaying DNS queries that were captured when transmitted over 134 early data, an attacker might be able to expose information about 135 those queries, even if encrypted. 137 For example, it's a common behavior for DNS servers to statefully 138 rotate the order of RRs when replying to DNS queries for an RRSet 139 that contains multiple RRs. If the order of rotation is predictable, 140 replaying a captured early data DNS query and observing the order of 141 RRs in DNS responses before and after the replayed query, might allow 142 the attacker to confirm whether the query targeted a specific name 143 that was suspected of being queried. 145 Servers SHOULD either use fixed ordering for multiple RRs in the same 146 DNS response or shuffle the RRs at random, but MUST NOT use stateful 147 and deterministic ordering across multiple queries. 149 4.2. Denial of Service 151 Accepting early data exposes a server to potential denial of service 152 through the replay of queries that might be expensive to handle. 154 When under load, a server MAY reject TLS early data such that the 155 client is forced to retry them after the handshake is completed. 157 4.3. Privacy 159 TBD 161 [[TODO: linkability (e.g. clients changing network, ...) and more?]] 163 5. IANA Considerations 165 This document has no actions for IANA. 167 6. Acknowledgments 169 Thanks to Martin Thomson, Mark Nottingham and Willy Tarreau for 170 writing [RFC8470] which heavily inspired this document, and to Daniel 171 Kahn Gillmor and Colm MacCarthaigh who also provided important ideas 172 and contributions. 174 7. References 176 7.1. Normative References 178 [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 179 and P. Hoffman, "Specification for DNS over Transport 180 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 181 2016, . 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, 185 DOI 10.17487/RFC2119, March 1997, 186 . 188 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 189 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 190 May 2017, . 192 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 193 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 194 . 196 7.2. Informative References 198 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 199 "Transport Layer Security (TLS) Application-Layer Protocol 200 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 201 July 2014, . 203 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 204 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 205 RFC 2136, DOI 10.17487/RFC2136, April 1997, 206 . 208 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 209 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 210 . 212 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 213 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 214 2018, . 216 Author's Address 218 Alessandro Ghedini 219 Cloudflare, Inc. 221 Email: alessandro@cloudflare.com