idnits 2.17.1 draft-ghedini-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1856 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: 1 error (**), 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 March 25, 2019 5 Expires: September 26, 2019 7 Using Early Data in DNS over TLS 8 draft-ghedini-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 September 26, 2019. 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 4.4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 TLS 1.3 [TLS13] defines a mechanism, called 0-RTT session resumption 66 or early data, that allows clients to send data to servers in the 67 first round-trip of a connection without having to wait for the TLS 68 handshake to complete. 70 This can be used to send DNS queries to DNS over TLS [DOT] servers 71 without incurring in the cost of the additional round-trip required 72 by the TLS handshake, and it can be useful in cases where new DNS 73 over TLS connections need to be established often such as on mobile 74 clients where the network might not be stable, or on resolvers where 75 keeping an open connection to many authoritative servers might not be 76 practical. 78 However, the use of early data allows an attacker to capture and 79 replay the encrypted DNS queries carried on the TLS connection. This 80 can have unwanted consequences and help in recovering information 81 about those queries. While [TLS13] describes tecniques to reduce the 82 likelihood of a replay attack, they are not perfect and still leave 83 some potential for exploitation. 85 2. Notational Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 3. Early Data in DNS over TLS 95 TODO: talk more about 0-RTT vs. 1-RTT security properties. 97 A server can signal to clients whether it is willing to accept early 98 data in future connections by providing the "early_data" TLS 99 extension as part of a TLS session ticket, as well as limit the 100 amount of early data it is willing to accept using the 101 "max_early_data_size" field of the "early_data" extension. 103 In addition to the mitigation mechanisms mandated in [TLS13] that 104 reduce the ability of an attacker to replay early data, but may not 105 completely eliminate it, a server that decided to offer early data to 106 clients MAY reject early data at the TLS layer, or delay the 107 processing of early data to after the handshake is completed. 109 If the server rejects early data at the TLS layer, a client MUST 110 forget information it optmisitically assumed about the onnection when 111 sending early data, such as the negotiated protocol [ALPN]. Any DNS 112 queries sent in early data will need to be sent again, unless the 113 client decides to abandon them. 115 TODO: forbid sending DNS updates in early data (RFC2136)? XFR? 116 Other query types? 118 4. Security Considerations 120 4.1. Information Exposure 122 By replaying DNS queries that were captured when transmitted over 123 early data, an attacker might be able to expose information about 124 those queries, even if encrypted. 126 For example, it's a common behavior for DNS servers to statefully 127 rotate the order of RRs when replying to DNS queries for an RRSet 128 that contains multiple RRs. If the order of rotation is predictable, 129 replaying a captured early data DNS query and observing the order of 130 RRs in DNS responses before and after the replayed query, might allow 131 an attacker to confirm whether the replayed query targeted a specific 132 name that was suspected of being queried without having to decrypt 133 it. 135 Servers SHOULD either use fixed ordering for multiple RRs in the same 136 DNS response or shuffle the RRs at random, but MUST NOT use stateful 137 and deterministic ordering across multiple queries. 139 4.2. Denial of Service 141 Accepting early data exposes a server to potential denial of service 142 through the replay of queries that might be expensive to handle. 144 When under load, a server MAY reject TLS early data such that the 145 client is forced to retry them after the handshake is completed. 147 4.3. Privacy 149 TODO: linkability (e.g. clients changing network, ...) and more? 151 4.4. Acknowledgments 153 This document was heavily inspired by [RFC8470]. Daniel Kahn Gillmor 154 and Colm MacCarthaigh also provided important ideas and 155 contributions. 157 5. References 159 5.1. Normative References 161 [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 162 and P. Hoffman, "Specification for DNS over Transport 163 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 164 2016, . 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, 168 DOI 10.17487/RFC2119, March 1997, 169 . 171 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 172 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 173 May 2017, . 175 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 176 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 177 . 179 5.2. Informative References 181 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 182 "Transport Layer Security (TLS) Application-Layer Protocol 183 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 184 July 2014, . 186 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 187 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 188 2018, . 190 Author's Address 192 Alessandro Ghedini 193 Cloudflare, Inc. 195 Email: alessandro@cloudflare.com