idnits 2.17.1 draft-ietf-tls-semistatic-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([SIGMA], [I-D.ietf-tls-tls13]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 17, 2020) is 1559 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) == Unused Reference: 'I-D.ietf-httpbis-http2-secondary-certs' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-exported-authenticator' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 316, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-http2-secondary-certs-05 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-11 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-05 == Outdated reference: A later version (-14) exists of draft-irtf-cfrg-randomness-improvements-08 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Standards Track N. Sullivan 5 Expires: July 20, 2020 Cloudflare 6 C. Wood 7 Apple Inc. 8 January 17, 2020 10 Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 11 draft-ietf-tls-semistatic-dh-00 13 Abstract 15 TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman 16 exchange modelled after SIGMA [SIGMA]. This design is suitable for 17 endpoints whose certified credential is a signing key, which is the 18 common situation for current TLS servers. This document describes a 19 mode of TLS 1.3 in which one or both endpoints have a certified DH 20 key which is used to authenticate the exchange. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 20, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Certificate Format . . . . . . . . . . . . . . . . . . . . . 5 60 5. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Certificate Verify Computation . . . . . . . . . . . . . 5 62 5.2. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 9.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 DISCLAIMER: This is a work-in-progress draft and has not yet seen 74 significant security analysis. Thus, this draft should not be used 75 as a basis for building production systems. 77 TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman 78 exchange modeled after SIGMA [SIGMA]. This design is suitable for 79 endpoints whose certified credential is a signing key, which is the 80 common situation for current TLS servers, which is why it was 81 selected for TLS 1.3. 83 However, it is also possible - although currently rare - for 84 endpoints to have a credential which is an (EC)DH key. This can 85 happen in one of two ways: 87 o They may be issued a certificate with an (EC)DH key, as specified 88 for instance in [I-D.ietf-curdle-pkix] 90 o They may have a signing key which they use to generate a delegated 91 credential [I-D.ietf-tls-subcerts] containing an (EC)DH key. 93 In these situations, a signed DH exchange is not appropriate, and 94 instead a design in which the server authenticates via its long-term 95 (EC)DH key is suitable. This document describes such a design 96 modeled on that described in OPTLS [KW16]. 98 This design has a number of potential advantages over the signed 99 exchange in TLS 1.3, specifically: 101 o If the end-entity certificate contains an (EC)DH key, TLS can 102 operate with a single asymmetric primitive (Diffie-Hellman). The 103 PKI component will still need signatures, but the TLS stack need 104 not have one. Note that this advantage is somewhat limited if the 105 (EC)DH key is in a delegated credential, but that allows for a 106 clean transition to (EC)DH certificates. 108 o It is more resistant to random number generation failures on the 109 server because the attacker needs to have both the server's long- 110 term (EC)DH key and the ephemeral (EC)DH key in order to compute 111 the traffic secrets. [Note: 112 [I-D.irtf-cfrg-randomness-improvements] describes a technique for 113 accomplishing this with a signed exchange.] 115 o If the server has a comparatively slow signing cert (e.g., P-256) 116 it can amortize that signature over a large number of connections 117 by creating a delegated credential with an (EC)DH key from a 118 faster group (e.g., X25519). 120 o Because there is no signature, the server has deniability for the 121 existence of the communication. Note that it could always have 122 denied the contents of the communication. 124 This exchange is not generally faster than a signed exchange if 125 comparable groups are used. In fact, if delegated credentials are 126 used, it may be slower on the client as it has to validate the 127 delegated credential, though the result may be cached. 129 2. Protocol Overview 131 The overall protocol flow remains the same as that in ordinary TLS 132 1.3, as shown below: 134 Client Server 136 Key ^ ClientHello 137 Exch | + key_share* 138 | + signature_algorithms* 139 | + psk_key_exchange_modes* 140 v + pre_shared_key* --------> 141 ServerHello ^ Key 142 + key_share* | Exch 143 + pre_shared_key* v 144 {EncryptedExtensions} ^ Server 145 {CertificateRequest*} v Params 146 {Certificate*} ^ 147 {CertificateVerify*} | Auth 148 {Finished} v 149 <-------- [Application Data*] 150 ^ {Certificate*} 151 Auth | {CertificateVerify*} 152 v {Finished} --------> 153 [Application Data] <-------> [Application Data] 155 As usual, the client and server each supply an (EC)DH share in their 156 "key_share" extensions. However, in addition, the server supplies a 157 (signed) static (EC)DH share in its Certificate message, either 158 directly in its end-entity certificate or in a delegated credential. 159 The client and server then perform two (EC)DH exchanges: 161 o Between the client and server "key_share" values to form an 162 ephemeral secret (ES). This is the same value as is computed in 163 TLS 1.3 currently. 165 o Between the client's "key_share" and the server's static share, to 166 form a static secret (SS). 168 Note that this means that the server's static secret MUST be in the 169 same group as selected group for the ephemeral (EC)DH exchange. 171 The handshake then proceeds as usual, except that: 173 o Instead of containing a signature, the CertificateVerify contains 174 a MAC of the handshake transcript, computed based on SS. 176 o SS is mixed into the key schedule at the last HKDF-Extract stage 177 (where currently a 0 is used as the IKM input). 179 3. Negotiation 181 In order to negotiate this mode, we treat the (EC)DH MAC as if it 182 were a signature and negotiate it with a set of new signature scheme 183 values: 185 enum { 186 sig_p256(0x0901), 187 sig_p384(0x0902), 188 sig_p521(0x0903), 189 sig_x52219(0x0904), 190 sig_x448(0x0905), 191 } SignatureScheme; 193 When present in the "signature_algorithms" extension or 194 CertificateVerify.signature_scheme, these values indicate DH MAC with 195 the specified key exchange mode. These values MUST NOT appear in 196 "signature_algorithms_cert". 198 Before sending and upon receipt, endpoints MUST ensure that the 199 signature scheme is consistent with the ephemeral (EC)DH group in 200 use. 202 4. Certificate Format 204 Like signing keys, static DH keys are carried in the Certificate 205 message, either directly in the EE certificate, or in a delegated 206 credential. In either case, the OID for the SubjectPublicKeyInfo 207 MUST be appropriate for use with (EC)DH key establishment. If in a 208 certificate, the key usage and EKU MUST also be set appropriately See 209 [I-D.ietf-curdle-pkix] and [[TBD: P-256, etc.]] for specific details 210 about these formats. 212 5. Cryptographic Details 214 5.1. Certificate Verify Computation 216 Instead of a signature, the server proves knowledge of the private 217 key associated with its static share by computing a MAC over the 218 handshake transcript using SS. The transcript thus far includes all 219 messages up to and including Certificate, i.e.: 221 Transcript-Hash(Handshake Context, Certificate) 223 The MAC key - SS-Base-Key - is derived from SS as follows: 225 SS-Base-Key = HKDF-Extract(0, SS) 227 The MAC is then computed using the Finished computation described in 228 [I-D.ietf-tls-tls13] Section 4.4, with SS-Base-Key as the Base Key 229 value. Receivers MUST validate the MAC and terminate the handshake 230 with a "decrypt_error" alert upon failure. 232 Note that this means that the server sends two MAC computations in 233 the handshake, one in CertificateVerify using SS and the other in 234 Finished using the Master Secret. These MACs serve different 235 purposes: the first authenticates the handshake and the second proves 236 possession of the ephemeral secret. 238 5.2. Key Schedule 240 The final HKDF-Extract stage of the TLS 1.3 key schedule has an HKDF- 241 Extract with the IKM of 0. When static key exchange is negotiated, 242 that 0 is replaced with SS, as shown below. 244 ... 245 Derive-Secret(., "derived", "") 246 | 247 v 248 SS -> HKDF-Extract = Master Secret 249 | 250 +-----> Derive-Secret(., "c ap traffic", 251 | ClientHello...server Finished) 252 | = client_application_traffic_secret_0 253 | 254 ... 256 6. Client Authentication 258 [[OPEN ISSUE]] In principle, we can do client authentication the same 259 way, with the client's DH key in Certificate and a MAC in 260 CertificateVerity. However, it's less good because the client's 261 static key doesn't get mixed in at all. Also, client DH keys seem 262 even further off. 264 7. Security Considerations 266 [[OPEN ISSUE: This design requires formal analysis.]] 268 This is intended to have roughly equivalent security properties to 269 current TLS 1.3, except for the points raised in the introduction. 271 Open questions: 273 o Should semi-static key shares be mixed into the key schedule for 274 client authentication? 276 o Should we add support for early data encryption using a semi- 277 static key? 279 8. IANA Considerations 281 IANA [SHOULD add/has added] the new code points specified in 282 Section 3 to the TLS 1.3 signature scheme registry, with a 283 "recommended" value of TBD. 285 9. References 287 9.1. Normative References 289 [I-D.ietf-curdle-pkix] 290 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 291 Ed25519, Ed448, X25519 and X448 for use in the Internet 292 X.509 Public Key Infrastructure", draft-ietf-curdle- 293 pkix-10 (work in progress), May 2018. 295 [I-D.ietf-httpbis-http2-secondary-certs] 296 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 297 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 298 http2-secondary-certs-05 (work in progress), November 299 2019. 301 [I-D.ietf-tls-exported-authenticator] 302 Sullivan, N., "Exported Authenticators in TLS", draft- 303 ietf-tls-exported-authenticator-11 (work in progress), 304 December 2019. 306 [I-D.ietf-tls-subcerts] 307 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 308 "Delegated Credentials for TLS", draft-ietf-tls- 309 subcerts-05 (work in progress), November 2019. 311 [I-D.ietf-tls-tls13] 312 Rescorla, E., "The Transport Layer Security (TLS) Protocol 313 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 314 March 2018. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 9.2. Informative References 323 [I-D.irtf-cfrg-randomness-improvements] 324 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 325 and C. Wood, "Randomness Improvements for Security 326 Protocols", draft-irtf-cfrg-randomness-improvements-08 327 (work in progress), November 2019. 329 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 330 Proceedings of Euro S"P 2016 , 2016, 331 . 333 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 334 authenticated Diffie-Hellman and its use in the IKE 335 protocols", Proceedings of CRYPTO 2003 , 2003. 337 Authors' Addresses 339 Eric Rescorla 340 Mozilla 342 Email: ekr@rtfm.com 344 Nick Sullivan 345 Cloudflare 347 Email: nick@cloudflare.com 349 Christopher A. Wood 350 Apple Inc. 351 One Apple Park Way 352 Cupertino, California 95014 353 United States of America 355 Email: cawood@apple.com