idnits 2.17.00 (12 Aug 2021) /tmp/idnits25273/draft-dkg-tls-reject-static-dh-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 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 1263 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-00 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 5 69 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 70 5.1. Timing of rejection for detecting DH reuse . . . . . . . 5 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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 session as the client, impersonating the 159 client to the server. The middlebox can also replay any application- 160 layer data that the server might use to establish client identity 161 (e.g. passwords or HTTP cookies). Since many TLS servers associate a 162 TLS session with a client identity or application-layer bearer 163 tokens, this effectively allows the middlebox to impersonate the 164 client. This violates expectations of authenticity (because the 165 server does not know that the client is really the client) and replay 166 resistance (because the server can replay any application layer data 167 sent by the client to the server without the client's knowledge). 169 2.6. Static DH implementations are error-prone 171 Implementations of static DH schemes are known to be difficult to 172 implement correctly. See for example [invalid-curves-TLS-ECDH]. 173 Proposals of this nature are likely to introduce new forms of 174 implementation error that would be avoided by standard 175 implementations. 177 3. Mitigations against static DH 179 Given the concerns raised in Section 2, responsible TLS clients that 180 want to provide the standard TLS guarantees need to implement clear 181 mitigations against risky peers. 183 3.1. TLS Clients MUST Reject server certificates marked for use with 184 static DH 186 [MIDDLEBOX] suggests that most servers using the designated scheme 187 will use a certificate with so-called "VisibilityInformation" stored 188 in the "subjectAltName" X.509v3 extension (see [RFC5280]), as an 189 "otherName" field with a specific "type-id" of 0.4.0.3523.3.1. 191 0.4.0.3523.3.1 192 { itu-t(0) 193 identified-organization(4) 194 etsi(0) 195 msp(3523) 196 etls(3) 197 visibility(1) } 199 Figure 1: OID of VisibilityInformation `type-id` 201 A TLS client that receives a Certificate message from the server 202 where the end entity certificate contains any such element in its 203 "subjectAltName" MUST terminate the TLS connection with a fatal 204 "bad_certificate" alert. 206 3.2. Client detection and rejection of static DH 208 Annex A of [MIDDLEBOX] suggests that some servers may use pseudo- 209 static Diffie-Hellman without this "subjectAltName" in their 210 certificate. 212 To defend against leakage from these servers, responsible TLS clients 213 that can afford to keep state SHOULD keep track of the DH shares sent 214 by the server over the course of multiple connections. 216 If the TLS client notices that it has been offered the same DH share 217 more than once, it SHOULD terminate the TLS connection upon handshake 218 completion with a fatal "decrypt_error" alert. 220 3.3. Servers MUST avoid accidental DHE share reuse 222 Given the concerns in Section 2 and the necessary client mitigations 223 in the subsections above, servers need to avoid giving the appearance 224 of using non-ephemeral DH. Servers MUST NOT reuse ephemeral DH 225 shares. 227 4. Security Considerations 229 This entire document is an attempt to address security considerations 230 associated with a non-standard use of TLS. 232 5. Privacy Considerations 234 5.1. Timing of rejection for detecting DH reuse 236 Clients that are not careful with timing may introduce a minor 237 linkability concern when implementing the mitigation described in 238 Section 3.2. 240 A network adversary capable of observing some connections, and 241 actively interfering with others may be able to identify a TLS client 242 of a standard TLS server across different connections by observing a 243 successul connection, and then impersonating the server on a 244 subsequent connection from an unknown client to the same server while 245 re-using the server's previously-offered DH share. If the client 246 rejects this share early (e.g upon receipt of the ServerHello, but 247 before the handshake completes), then the network adversary can re- 248 identify the client. 250 Note that this likability attack is mitigated by waiting until 251 handshake completion to reject the server's offer, since a normal 252 network adversary will not be able to complete the handshake 253 legitimately, since it does not know the server's credentials, so 254 rejection of the connection at that time will not allow the server to 255 distinguish the specific client from any other TLS client. 257 6. IANA Considerations 259 There are no IANA considerations for this document. 261 7. Acknowledgements 263 Thanks to numerous commenters on the tls@ietf.org mailing who 264 explained why using static DH presents a risk to TLS users. 266 8. References 268 8.1. Normative References 270 [MIDDLEBOX] 271 European Telecommunications Standards Institute, 272 "Middlebox Security Protocol; Part 3: Profile for 273 enterprise network and data centre access control", 274 ETSI TS 103 523-3, October 2018. 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 282 Housley, R., and W. Polk, "Internet X.509 Public Key 283 Infrastructure Certificate and Certificate Revocation List 284 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 285 . 287 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 288 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 289 . 291 8.2. Informative References 293 [draft-green-tls-static-dh-in-tls13-01] 294 Green, M., "Data Center use of Static Diffie-Hellman in 295 TLS 1.3", July 2017. 297 [invalid-curves-TLS-ECDH] 298 Somorovsky, J., "Practical Invalid Curve Attacks on TLS- 299 ECDH", September 2015. 301 Author's Address 303 Daniel Kahn Gillmor 304 ACLU 306 Email: dkg@fifthhorseman.net