idnits 2.17.1 draft-boucadair-dots-earlydata-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 Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 78: '...cation protocols MUST NOT use 0-RTT da...' RFC 2119 keyword, line 88: '...ccepts 0-RTT, it MUST implement one of...' RFC 2119 keyword, line 121: '... [RFC2616]). The GET method is safe; therefore, it MUST NOT take...' RFC 2119 keyword, line 123: '...d DELETE methods MUST be performed in ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2019) is 1913 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2616' is mentioned on line 121, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-27 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Informational T. Reddy 5 Expires: August 2, 2019 McAfee 6 January 29, 2019 8 Using Early Data in DOTS 9 draft-boucadair-dots-earlydata-00 11 Abstract 13 This document discusses to what extent it is safe to send DOTS signal 14 channel messages as Early Data in TLS 1.3. 16 This document is not intended to be published as an RFC. It is 17 edited to help understanding the conclusion about the safeness of 18 using DOTS signal channel messages as early data. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 2, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Reminder . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Replay the Same Request to the Same DOTS Server . . . . . . . 3 57 4. Fork a Request to Multiple Servers . . . . . . . . . . . . . 4 58 5. Fork a Request to Multiple Server-Domain Gateways . . . . . . 4 59 6. Fork a Request to Multiple Client-Domain Gateways . . . . . . 5 60 7. Block a Response from a DOTS Server or DOTS Gateway . . . . . 5 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Context 68 Section E.5 of [RFC8446] states the following: 70 Replayable 0-RTT data presents a number of security threats to 71 TLS- using applications, unless those applications are 72 specifically engineered to be safe under replay (minimally, this 73 means idempotent, but in many cases may also require other 74 stronger conditions, such as constant-time response). 76 ... 78 Application protocols MUST NOT use 0-RTT data without a profile 79 that defines its use. That profile needs to identify which 80 messages or interactions are safe to use with 0-RTT and how to 81 handle the situation when the server rejects 0-RTT and falls back 82 to 1-RTT. 84 To that aim, [I-D.ietf-dots-signal-channel] includes the following: 86 Section 8 of [RFC8446] discusses some mechanisms to implement to 87 limit the impact of replay attacks on 0-RTT data. If the DOTS 88 server accepts 0-RTT, it MUST implement one of these mechanisms. 89 A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. 90 The DOTS signal channel messages sent as early data by the DOTS 91 client are idempotent requests. As a reminder, Message ID 92 (Section 3 of [RFC7252]) is changed each time a new CoAP request 93 is sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized 94 in each CoAP request. The DOTS server(s) can use Message ID and 95 Token in the DOTS signal channel message to detect replay of early 96 data, and accept 0-RTT data at most once. Furthermore, 'mid' 97 value is monotonically increased by the DOTS client for each 98 mitigation request, attackers replaying mitigation requests with 99 lower numeric 'mid' values and overlapping scopes with mitigation 100 requests having higher numeric 'mid' values will be rejected 101 systematically by the DOTS server. 103 Owing to the aforementioned protections, especially those afforded 104 by CoAP deduplication (Section 4.5 of [RFC7252]) and RFC 8446 105 anti-replay mechanisms, all DOTS signal channel requests are safe 106 to transmit in TLS 1.3 as early data. 108 This document is intended to provide more elaboration to motivate the 109 above conclusion included in [I-D.ietf-dots-signal-channel]. 111 2. Reminder 113 DOTS signal channel relies on CoAP methods (GET, PUT, and DELETE) 114 that are designed to adhere to the following design (Section 5.1 of 115 [RFC7252]): 117 CoAP supports the basic methods of GET, POST, PUT, and DELETE, 118 which are easily mapped to HTTP. They have the same properties of 119 safe (only retrieval) and idempotent (you can invoke it multiple 120 times with the same effects) as HTTP (see Section 9.1 of 121 [RFC2616]). The GET method is safe; therefore, it MUST NOT take 122 any other action on a resource other than retrieval. The GET, 123 PUT, and DELETE methods MUST be performed in such a way that they 124 are idempotent. POST is not idempotent, because its effect is 125 determined by the origin server and dependent on the target 126 resource; it usually results in a new resource being created or 127 the target resource being updated. 129 Note also that Message ID (Section 3 of [RFC7252]) is changed each 130 time a new CoAP request is sent, and the Token (Section 5.3.1 of 131 [RFC7252]) is randomized in each CoAP request. Message ID is 132 particularly used by a CoAP implementation for message deduplication 133 as discussed in Section 4.5 of [RFC7252]. 135 3. Replay the Same Request to the Same DOTS Server 137 This attack assumes that an eavesdropper who can observe the 0-RTT 138 data from a DOTS client and then replays the ClientHello and early 139 data to the same DOTS server. 141 The DOTS server uses Message ID and Token in the DOTS signal channel 142 message to detect replay of early data, and accepts 0-RTT data at 143 most once. 145 4. Fork a Request to Multiple Servers 147 This attack assumes that an eavesdropper who can observe the 0-RTT 148 data from a DOTS client to a DOTS server and then replays the 149 ClientHello and early data to other DOTS servers. 151 Obviousily, the replayed message will be discarded if distinct 152 credentials are used per DOTS server or if the scope of the request 153 is not under the responsibility of a DOTS server. 155 As a reminder, the DOTS servers in the same domain have to maintain a 156 globally consistant server state to handle the following scenarios: 158 o DOTS client using different DOTS servers for DOTS signal and data 159 channel protocols, synchronization of server state is required to 160 detect conflicts between mitigation requests and existing accept- 161 lists. 163 o DOTS clients using different DOTS servers to send mitigation 164 requests, synchronization of server state is essential to detect 165 conflicting mitigation requests from DOTS clients. 167 o DOTS client sends mitigation requests with overlapping scopes to 168 different DOTS servers, synchronization of server state is 169 essential to detect conflicting mitigation request from the DOTS 170 clients. 172 It is recommended to implement RFC 8446 anti-replay mechanisms by 173 DOTS servers of a domain to accept 0-RTT data at most once and 174 silently discard the duplicate the request. Note that duplicate 175 requests will also be discarded due to conflict detection policies 176 described in [I-D.ietf-dots-signal-channel] (overlapping scopes). 178 As a side note, the procedure to select and/or contact DOTS servers 179 when multiple servers are configured to a DOTS client is out of scope 180 of [I-D.ietf-dots-signal-channel]. 182 5. Fork a Request to Multiple Server-Domain Gateways 184 This attack assumes that an eavesdropper who can observe the 0-RTT 185 data from a DOTS client to a server-domain DOTS gateway and then 186 replays the ClientHello and early data to other server-domain DOTS 187 gateways. 189 The ultimate DOTS server (i.e., the server to which the requests are 190 relayed by the server-domain gateways) uses then Message ID and Token 191 in the DOTS signal channel messages to detect replay of early data, 192 and accepts 0-RTT data at most once. 194 6. Fork a Request to Multiple Client-Domain Gateways 196 This attack assumes that an eavesdropper who can observe the 0-RTT 197 data from a DOTS client to a client-domain DOTS gateway and then 198 replays the ClientHello and early data to other client-domain DOTS 199 gateways. 201 If only one DOTS server is configured to all these client-domain 202 gateways, then this DOTS server will detect duplicate requests 203 because all these requests will expose the same Message ID, and 204 Token. 206 If multiple DOTS servers are deployed, then the measures described in 207 Section 4 have to be followed. 209 7. Block a Response from a DOTS Server or DOTS Gateway 211 This attack assumes the following: 213 o The DOTS client is provisioned with multiple DOTS servers (or DOTS 214 gateways). 216 o The attacker blocks the response received from the DOTS server (or 217 DOTS gateway) for early data. 219 o In the absence of the response, the DOTS client contacts another 220 DOTS server (or DOTS gateway). 222 It is recommended to implement RFC 8446 anti-replay mechanisms by 223 DOTS servers of a domain to accept 0-RTT data at most once and 224 silently discard the duplicate the request. 226 Note that when the new request is received by another DOTS server, 227 conflict detection discussed in [I-D.ietf-dots-signal-channel] will 228 be used. The duplicate request will be rejected by the DOTS server 229 because the mitigation request has overlapping target with a previous 230 mitigation request from the same DOTS client. 232 8. Security Considerations 234 The document discusses security considerations related to the use of 235 TLS 1.3 0-RTT feature for DOTS signal channel messages. 237 9. IANA Considerations 239 This document does not require any action from IANA. 241 10. Normative References 243 [I-D.ietf-dots-signal-channel] 244 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 245 Teague, "Distributed Denial-of-Service Open Threat 246 Signaling (DOTS) Signal Channel Specification", draft- 247 ietf-dots-signal-channel-27 (work in progress), January 248 2019. 250 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 251 Application Protocol (CoAP)", RFC 7252, 252 DOI 10.17487/RFC7252, June 2014, 253 . 255 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 256 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 257 . 259 Authors' Addresses 261 Mohamed Boucadair 262 Orange 263 Rennes 35000 264 France 266 Email: mohamed.boucadair@orange.com 268 Tirumaleswar Reddy 269 McAfee, Inc. 270 Embassy Golf Link Business Park 271 Bangalore, Karnataka 560071 272 India 274 Email: TirumaleswarReddy_Konda@McAfee.com