idnits 2.17.00 (12 Aug 2021) /tmp/idnits61448/draft-dkg-tls-reject-static-dh-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 5, 2018) is 1256 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MIDDLEBOX' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Standards Track December 5, 2018 5 Expires: June 8, 2019 7 TLS clients should reject static Diffie-Hellman 8 draft-dkg-tls-reject-static-dh-01 10 Abstract 12 This draft addresses problematic proposals that contradict the 13 expected security properties of TLS. In particular, the ETSI 14 "Middlebox Security Protocol" standard deliberately weakens the 15 cryptographic guarantees of TLS unilaterally by the server, using 16 static Diffie-Hellman keys where ephemeral keys are expected. 17 Responsible TLS clients should avoid connecting to servers that 18 appear to implement such a specification. 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 June 8, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Problems with static DH . . . . . . . . . . . . . . . . . . . 3 57 2.1. Limited cryptanalysis . . . . . . . . . . . . . . . . . . 3 58 2.2. Lack of forward secrecy . . . . . . . . . . . . . . . . . 3 59 2.3. Confidentiality violation by middleboxes . . . . . . . . 3 60 2.4. Message tampering by middleboxes . . . . . . . . . . . . 4 61 2.5. Session resumption by middleboxes . . . . . . . . . . . . 4 62 2.6. Static DH implementations are error-prone . . . . . . . . 4 63 3. Mitigations against static DH . . . . . . . . . . . . . . . . 4 64 3.1. TLS Clients MUST Reject server certificates marked for 65 use with static DH . . . . . . . . . . . . . . . . . . . 5 66 3.2. Client detection and rejection of static DH . . . . . . . 5 67 3.3. Servers MUST avoid accidental DHE share reuse . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 70 5.1. Timing of rejection for detecting DH reuse . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 TLS 1.3 [RFC8446] promises strong cryptographic properties for a two- 81 party protocol. These properties are the result of extensive 82 engineering and analysis, and are intended to afford users of TLS 83 baseline expectations of confidentiality, integrity, authentication, 84 as well as more subtle properties like replay resistance and forward 85 secrecy. 87 [draft-green-tls-static-dh-in-tls13-01] proposed the use of a pseudo- 88 static DH share, and was discussed at length in the IETF TLS working 89 group as a mechanism to modify the security properties of TLS for 90 operations within the "enterprise datacenter". The working group 91 failed to reach consensus on this draft, in large part because of the 92 changes it created to the TLS security model, the relative lack of 93 cryptanalysis those changes have received, and the risks to users on 94 the broader Internet. 96 [MIDDLEBOX] was recently formalized by ETSI, and offers a very 97 similar mechanism to [draft-green-tls-static-dh-in-tls13-01]. In 98 particular, MIDDLEBOX addresses none of the concerns raised during 99 the earlier discussion, and is not fit for the goals of TLS. 101 This document discusses how responsible TLS clients can avoid the 102 risks inherent in such a design, by refusing connections to peers 103 that implement it. 105 1.1. Key Words 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 docuoment are to be interpreted as described in [RFC2119]. 111 2. Problems with static DH 113 [MIDDLEBOX] proposes the use of static Diffie-Hellman keys where TLS 114 expects ephemeral Diffie-Hellman keys. Furthermore, it encourages 115 the sharing of those secret keys with third parties ("middleboxes"). 116 This section documents some of the known problems with this design. 118 2.1. Limited cryptanalysis 120 TLS 1.3 as specified has been subject to a substantial amount of 121 cryptanalysis, including formal methods that provide security 122 guarantees. Much of that cryptanalysis takes as a given that the 123 ephemeral DH keys are never re-used. Deliberately re-using DH keys 124 invalidates some of this cryptanalysis, and discards the formal 125 guarantees provided. 127 2.2. Lack of forward secrecy 129 Standard ephemeral Diffie-Hellman key exchange permits simple forward 130 secrecy by means of each peer discarding the secrets used to 131 establish the session. Reusing a DH key requires retention of the 132 key, which means that the expected forward secrecy properties are 133 lost. 135 2.3. Confidentiality violation by middleboxes 137 A Middlebox which has access to the DH key of a given session can 138 read the contents of the messages in that session by deriving the 139 client_application_traffic_secret and 140 server_application_traffic_secret and using it to decrypt 141 ApplicationData messages. This appears to be the stated goal of 142 [MIDDLEBOX] but typical TLS clients unwittingly connecting to such a 143 server may still expect confidentiality against third party 144 eavesdropping. This implementation violates that expectation. 146 2.4. Message tampering by middleboxes 148 A Middlebox which has access to the DH key of a given session can 149 derive all necessary secrets of the session, and is capable of 150 modifying messages in flight without detection by either peer. This 151 violates the integrity guarantees of TLS. 153 2.5. Session resumption by middleboxes 155 A middlebox with access to the DH key of a given session can derive 156 the resumption_master_secret, and can also view any NewSessionTicket 157 messages sent by the server. The middlebox can use that information 158 to subsequently resume the client's old session. The middlebox can 159 also replay any application-layer data that the server might use to 160 establish client identity (e.g. passwords, HTTP cookies, or other 161 bearer tokens). 163 Since many TLS servers associate client identity with a TLS session 164 and/or application-layer bearer tokens, this effectively allows the 165 middlebox to impersonate the client. This violates expectations of 166 authenticity (because the server does not know whether a resuming 167 client is really the expected client) and replay resistance (because 168 the middlebox can replay any application layer data sent by the 169 client to the server without the client's knowledge). 171 2.6. Static DH implementations are error-prone 173 Implementations of static DH schemes are known to be difficult to 174 implement correctly. See for example [invalid-curves-TLS-ECDH]. 175 Proposals of this nature are likely to introduce new forms of 176 implementation error that would be avoided by standard 177 implementations. 179 3. Mitigations against static DH 181 Given the concerns raised in Section 2, responsible TLS clients that 182 want to provide the standard TLS guarantees need to implement clear 183 mitigations against risky peers. This section documents useful 184 mitigations. 186 3.1. TLS Clients MUST Reject server certificates marked for use with 187 static DH 189 [MIDDLEBOX] suggests that most servers using the designated scheme 190 will use a certificate with so-called "VisibilityInformation" stored 191 in the "subjectAltName" X.509v3 extension (see [RFC5280]), as an 192 "otherName" field with a specific "type-id" of 0.4.0.3523.3.1. 194 0.4.0.3523.3.1 195 { itu-t(0) 196 identified-organization(4) 197 etsi(0) 198 msp(3523) 199 etls(3) 200 visibility(1) } 202 Figure 1: OID of VisibilityInformation `type-id` 204 A TLS client that receives a Certificate message from the server 205 where the end entity certificate contains any such element in its 206 "subjectAltName" MUST terminate the TLS connection with a fatal 207 "bad_certificate" alert. 209 3.2. Client detection and rejection of static DH 211 Annex A of [MIDDLEBOX] suggests that some servers may use pseudo- 212 static Diffie-Hellman without this "subjectAltName" in their 213 certificate. 215 To defend against leakage from these servers, responsible TLS clients 216 that can afford to keep state SHOULD keep track of the DH shares sent 217 by the server over the course of multiple connections. 219 If the TLS client notices that it has been offered the same DH share 220 more than once, it SHOULD terminate the TLS connection upon handshake 221 completion with a fatal "decrypt_error" alert. 223 3.3. Servers MUST avoid accidental DHE share reuse 225 Given the concerns in Section 2 and the necessary client mitigations 226 in the subsections above, servers need to avoid giving the appearance 227 of using non-ephemeral DH. Servers MUST NOT reuse ephemeral DH 228 shares. 230 4. Security Considerations 232 This entire document is an attempt to address security considerations 233 associated with the use of static Diffie-Hellman keys in TLS where 234 ephemeral Diffie-Hellman keys are expected. 236 5. Privacy Considerations 238 5.1. Timing of rejection for detecting DH reuse 240 Clients that are not careful with timing may introduce a minor 241 linkability concern when implementing the mitigation described in 242 Section 3.2. 244 Consider a network adversary with the following capabilities: 246 o can observe some connections 248 o can actively interfere with other connections 250 o is willing to cause connection failures in order to link client 251 sessions 253 Such an adversary may be able to identify a TLS client of a standard 254 TLS server across different connections by: 256 o observing a successul connection, recording the server's 257 "server_share" value in the "key_share" extension to "ServerHello" 259 o interfering sith subsequent connections to the same server from 260 unknown clients 262 o each interference re-uses the server's previously-offered 263 "server_share" value. 265 If the client rejects this repeated share early (e.g upon receipt of 266 the "ServerHello", but before the handshake completes), then the 267 network adversary can re-identify the client as being the one that 268 saw the share recently. 270 Note that this linkability attack is mitigated by waiting until 271 handshake completion to reject the server's offer, since a normal 272 network adversary does not know the server's credentials, so it will 273 not be able to complete the handshake legitimately. So rejection of 274 the connection at end of handshake will not allow the server to 275 distinguish the specific client from any other TLS client. 277 6. IANA Considerations 279 There are no IANA considerations for this document. 281 7. Acknowledgements 283 Thanks to numerous commenters on the tls@ietf.org mailing who 284 explained why using static DH presents a risk to TLS users. 286 8. References 288 8.1. Normative References 290 [MIDDLEBOX] 291 European Telecommunications Standards Institute, 292 "Middlebox Security Protocol; Part 3: Profile for 293 enterprise network and data centre access control", 294 ETSI TS 103 523-3, October 2018. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 302 Housley, R., and W. Polk, "Internet X.509 Public Key 303 Infrastructure Certificate and Certificate Revocation List 304 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 305 . 307 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 308 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 309 . 311 8.2. Informative References 313 [draft-green-tls-static-dh-in-tls13-01] 314 Green, M., Droms, R., Housley, R., Turner, P., and S. 315 Fenter, "Data Center use of Static Diffie-Hellman in TLS 316 1.3", July 2017. 318 [invalid-curves-TLS-ECDH] 319 Jager, T., Schwenk, J., and J. Somorovsky, "Practical 320 Invalid Curve Attacks on TLS-ECDH", September 2015. 322 Author's Address 324 Daniel Kahn Gillmor 325 ACLU 327 Email: dkg@fifthhorseman.net