idnits 2.17.1 draft-ietf-dprive-early-data-00.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 (April 22, 2020) is 1458 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 DPRIVE A. Ghedini 3 Internet-Draft Cloudflare, Inc. 4 Intended status: Standards Track April 22, 2020 5 Expires: October 24, 2020 7 Using Early Data in DNS over TLS 8 draft-ietf-dprive-early-data-00 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 October 24, 2020. 33 Copyright Notice 35 Copyright (c) 2020 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Registry for DNS Resource Record (RR) TYPEs for TLS Early 58 Data . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 6.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 TLS 1.3 [TLS13] defines a mechanism, called 0-RTT session resumption 68 or early data, that allows clients to send data to servers in the 69 first round-trip of a resumed connection without having to wait for 70 the TLS handshake to complete. 72 This can be used to send DNS queries to DNS over TLS [DOT] servers 73 without incurring in the cost of the additional round-trip required 74 by the TLS handshake. This can provide significant performance 75 improvements in cases where new DNS over TLS connections need to be 76 established often such as on mobile clients where the network might 77 not be stable, or on resolvers where keeping an open connection to 78 many authoritative servers might not be practical. 80 However the use of early data allows an attacker to capture and 81 replay the encrypted DNS queries carried on the TLS connection. This 82 can have unwanted consequences and help in recovering information 83 about those queries. While [TLS13] describes tecniques to reduce the 84 likelihood of a replay attack, they are not perfect and still leave 85 some potential for exploitation. 87 2. Notational Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 3. Early Data in DNS over TLS 97 Early data forms a single stream of data along with other application 98 data, meaning that one or more DNS queries can either be partially or 99 fully contained within early data. Once the TLS handshake has 100 completed, the early data is known to not be a replayed copy of that 101 data, but this doesn't mean that it can't be replayed, or that it 102 hasn't already been replayed, in another connection. 104 A server can signal to clients whether it is willing to accept early 105 data in future connections by providing the "early_data" TLS 106 extension as part of a TLS session ticket, as well as limit the 107 amount of early data it is willing to accept using the 108 "max_early_data_size" field of the "early_data" extension. 110 In addition to the mitigation mechanisms mandated in [TLS13] that 111 reduce the ability of an attacker to replay early data, but may not 112 completely eliminate it, a server that decided to offer early data to 113 clients MAY reject early data at the TLS layer, or delay the 114 processing of early data after the handshake is completed. 116 If the server rejects early data at the TLS layer, a client MUST 117 forget information it optmisitically assumed about the onnection when 118 sending early data, such as the negotiated protocol [ALPN]. Any DNS 119 queries sent in early data will need to be sent again, unless the 120 client decides to abandon them. 122 Not all types of DNS messages are safe to be sent as early data, as 123 they might modfify the server's state, or expose sensitive data, 124 through replay. Clients MUST NOT use early data to send messages 125 that make use of opcodes other than "Query" and RR types not listed 126 in the registry defined in Section 5.1. Servers receiving any of 127 those messages MUST reply with a "FormErr" response code. 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 When accepting early data, servers SHOULD either use fixed ordering 146 for multiple RRs in the same DNS response or shuffle the RRs at 147 random, but MUST NOT use stateful and deterministic ordering across 148 multiple queries. 150 4.2. Denial of Service 152 Accepting early data exposes a server to potential denial of service 153 through the replay of queries that might be expensive to handle. 155 When under load, a server MAY reject TLS early data such that the 156 client is forced to retry them after the handshake is completed. 158 5. IANA Considerations 160 This document has no actions for IANA. 162 5.1. Registry for DNS Resource Record (RR) TYPEs for TLS Early Data 164 This document establishes a registry of DNS RR types that can be used 165 within TLS early data, titled "DNS Resource Record (RR) TYPEs for Use 166 with TLS Early Data", under the existing "Domain Name System (DNS) 167 Parameters" heading. 169 The entries in the registry are: 171 +--------+-----------------+ 172 | TYPE | Reference | 173 +--------+-----------------+ 174 | A | [this document] | 175 | | | 176 | NS | [this document] | 177 | | | 178 | CNAME | [this document] | 179 | | | 180 | SOA | [this document] | 181 | | | 182 | PTR | [this document] | 183 | | | 184 | MX | [this document] | 185 | | | 186 | TXT | [this document] | 187 | | | 188 | AAAA | [this document] | 189 | | | 190 | SRV | [this document] | 191 | | | 192 | DNAME | [this document] | 193 | | | 194 | DS | [this document] | 195 | | | 196 | DNSKEY | [this document] | 197 +--------+-----------------+ 199 The values in this registry MUST correspond to existing entries in 200 the "Resource Record (RR) TYPEs" registry. Specifically, the value 201 of the "TYPE" column for each entry in this new registry MUST match 202 the value of the "TYPE" column of an entry in the "Resource Record 203 (RR) TYPEs" registry. 205 6. References 207 6.1. Normative References 209 [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 210 and P. Hoffman, "Specification for DNS over Transport 211 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 212 2016, . 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, 216 DOI 10.17487/RFC2119, March 1997, 217 . 219 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 220 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 221 May 2017, . 223 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 224 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 225 . 227 6.2. Informative References 229 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 230 "Transport Layer Security (TLS) Application-Layer Protocol 231 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 232 July 2014, . 234 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 235 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 236 2018, . 238 Appendix A. Acknowledgments 240 Thanks to Martin Thomson, Mark Nottingham and Willy Tarreau for 241 writing [RFC8470] which heavily inspired this document, and to Daniel 242 Kahn Gillmor and Colm MacCarthaigh who also provided important ideas 243 and contributions. 245 Author's Address 247 Alessandro Ghedini 248 Cloudflare, Inc. 250 Email: alessandro@cloudflare.com