idnits 2.17.1 draft-rescorla-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 (October 22, 2018) is 2011 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 301, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-exported-authenticator' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 321, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-http2-secondary-certs-02 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-08 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-02 == Outdated reference: A later version (-14) exists of draft-irtf-cfrg-randomness-improvements-03 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: April 25, 2019 Cloudflare 6 C. Wood 7 Apple Inc. 8 October 22, 2018 10 Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 11 draft-rescorla-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 http://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 April 25, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 (http://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. Early Data and Resumption . . . . . . . . . . . . . . . . . . 6 64 7. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 10.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 DISCLAIMER: This is a work-in-progress draft and has not yet seen 75 significant security analysis. Analysis of the modified TLS 1.3 -21 76 Tamarin model is currently underway. Thus, this draft should not be 77 used as a basis for building production systems. 79 TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman 80 exchange modeled after SIGMA [SIGMA]. This design is suitable for 81 endpoints whose certified credential is a signing key, which is the 82 common situation for current TLS servers, which is why it was 83 selected for TLS 1.3. 85 However, it is also possible - although currently rare - for 86 endpoints to have a credential which is an (EC)DH key. This can 87 happen in one of two ways: 89 o They may be issued a certificate with an (EC)DH key, as specified 90 for instance in [I-D.ietf-curdle-pkix] 92 o They may have a signing key which they use to generate a delegated 93 credential [I-D.ietf-tls-subcerts] containing an (EC)DH key. 95 In these situations, a signed DH exchange is not appropriate, and 96 instead a design in which the server authenticates via its long-term 97 (EC)DH key is suitable. This document describes such a design 98 modeled on that described in OPTLS [KW16]. 100 This design has a number of potential advantages over the signed 101 exchange in TLS 1.3, specifically: 103 o If the end-entity certificate contains an (EC)DH key, TLS can 104 operate with a single asymmetric primitive (Diffie-Hellman). The 105 PKI component will still need signatures, but the TLS stack need 106 not have one. Note that this advantage is somewhat limited if the 107 (EC)DH key is in a delegated credential, but that allows for a 108 clean transition to (EC)DH certificates. 110 o It is more resistant to random number generation failures on the 111 server because the attacker needs to have both the server's long- 112 term (EC)DH key and the ephemeral (EC)DH key in order to compute 113 the traffic secrets. [Note: 114 [I-D.irtf-cfrg-randomness-improvements] describes a technique for 115 accomplishing this with a signed exchange.] 117 o If the server has a comparatively slow signing cert (e.g., P-256) 118 it can amortize that signature over a large number of connections 119 by creating a delegated credential with an (EC)DH key from a 120 faster group (e.g., X25519). 122 o Because there is no signature, the server has deniability for the 123 existence of the communication. Note that it could always have 124 denied the contents of the communication. 126 This exchange is not generally faster than a signed exchange if 127 comparable groups are used. In fact, if delegated credentials are 128 used, it may be slower on the client as it has to validate the 129 delegated credential, though the result may be cached. 131 2. Protocol Overview 133 The overall protocol flow remains the same as that in ordinary TLS 134 1.3, as shown below: 136 Client Server 138 Key ^ ClientHello 139 Exch | + key_share* 140 | + signature_algorithms* 141 | + psk_key_exchange_modes* 142 v + pre_shared_key* --------> 143 ServerHello ^ Key 144 + key_share* | Exch 145 + pre_shared_key* v 146 {EncryptedExtensions} ^ Server 147 {CertificateRequest*} v Params 148 {Certificate*} ^ 149 {CertificateVerify*} | Auth 150 {Finished} v 151 <-------- [Application Data*] 152 ^ {Certificate*} 153 Auth | {CertificateVerify*} 154 v {Finished} --------> 155 [Application Data] <-------> [Application Data] 157 As usual, the client and server each supply an (EC)DH share in their 158 "key_share" extensions. However, in addition, the server supplies a 159 (signed) static (EC)DH share in its Certificate message, either 160 directly in its end-entity certificate or in a delegated credential. 161 The client and server then perform two (EC)DH exchanges: 163 o Between the client and server "key_share" values to form an 164 ephemeral secret (ES). This is the same value as is computed in 165 TLS 1.3 currently. 167 o Between the client's "key_share" and the server's static share, to 168 form a static secret (SS). 170 Note that this means that the server's static secret MUST be in the 171 same group as selected group for the ephemeral (EC)DH exchange. 173 The handshake then proceeds as usual, except that: 175 o Instead of containing a signature, the CertificateVerify contains 176 a MAC of the handshake transcript, computed based on SS. 178 o SS is mixed into the key schedule at the last HKDF-Extract stage 179 (where currently a 0 is used as the IKM input). 181 3. Negotiation 183 In order to negotiate this mode, we treat the (EC)DH MAC as if it 184 were a signature and negotiate it with a set of new signature scheme 185 values: 187 enum { 188 sig_p256(0x0901), 189 sig_p384(0x0902), 190 sig_p521(0x0903), 191 sig_x52219(0x0904), 192 sig_x448(0x0905), 193 } SignatureScheme; 195 When present in the "signature_algorithms" extension or 196 CertificateVerify.signature_scheme, these values indicate DH MAC with 197 the specified key exchange mode. These values MUST NOT appear in 198 "signature_algorithms_cert". 200 Before sending and upon receipt, endpoints MUST ensure that the 201 signature scheme is consistent with the ephemeral (EC)DH group in 202 use. 204 4. Certificate Format 206 Like signing keys, static DH keys are carried in the Certificate 207 message, either directly in the EE certificate, or in a delegated 208 credential. In either case, the OID for the SubjectPublicKeyInfo 209 MUST be appropriate for use with (EC)DH key establishment. If in a 210 certificate, the key usage and EKU MUST also be set appropriately See 211 [I-D.ietf-curdle-pkix] and [[TBD: P-256, etc.]] for specific details 212 about these formats. 214 5. Cryptographic Details 216 5.1. Certificate Verify Computation 218 Instead of a signature, the server proves knowledge of the private 219 key associated with its static share by computing a MAC over the 220 handshake transcript using SS. The transcript thus far includes all 221 messages up to and including Certificate, i.e.: 223 Transcript-Hash(Handshake Context, Certificate) 225 The MAC key - SS-Base-Key - is derived from SS as follows: 227 SS-Base-Key = HKDF-Extract(0, SS) 229 The MAC is then computed using the Finished computation described in 230 [I-D.ietf-tls-tls13] Section 4.4, with SS-Base-Key as the Base Key 231 value. Receivers MUST validate the MAC and terminate the handshake 232 with a "decrypt_error" alert upon failure. 234 Note that this means that the server sends two MAC computations in 235 the handshake, one in CertificateVerify using SS and the other in 236 Finished using the Master Secret. These MACs serve different 237 purposes: the first authenticates the handshake and the second proves 238 possession of the ephemeral secret. 240 5.2. Key Schedule 242 The final HKDF-Extract stage of the TLS 1.3 key schedule has an HKDF- 243 Extract with the IKM of 0. When static key exchange is negotiated, 244 that 0 is replaced with SS, as shown below. 246 ... 247 Derive-Secret(., "derived", "") 248 | 249 v 250 SS -> HKDF-Extract = Master Secret 251 | 252 +-----> Derive-Secret(., "c ap traffic", 253 | ClientHello...server Finished) 254 | = client_application_traffic_secret_0 255 | 256 ... 258 6. Early Data and Resumption 260 [[OPEN ISSUE]] It seems like one ought to be able to publish the 261 server's static key and use it for 0-RTT, but actually we don't know 262 how to do the publication piece, so I think we should leave this out 263 for now. 265 7. Client Authentication 267 [[OPEN ISSUE]] In principle, we can do client authentication the same 268 way, with the client's DH key in Certificate and a MAC in 269 CertificateVerity. However, it's less good because the client's 270 static key doesn't get mixed in at all. Also, client DH keys seem 271 even further off. 273 8. Security Considerations 275 [[OPEN ISSUE: This design requires formal analysis.]] 277 This is intended to have roughly equivalent security properties to 278 current TLS 1.3, except for the points raised in the introduction. 280 Open questions: 282 o Should semi-static key shares be mixed into the key schedule for 283 client authentication? 285 9. IANA Considerations 287 IANA [SHOULD add/has added] the new code points specified in 288 Section 3 to the TLS 1.3 signature scheme registry, with a 289 "recommended" value of TBD. 291 10. References 293 10.1. Normative References 295 [I-D.ietf-curdle-pkix] 296 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 297 Ed25519, Ed448, X25519 and X448 for use in the Internet 298 X.509 Public Key Infrastructure", draft-ietf-curdle- 299 pkix-10 (work in progress), May 2018. 301 [I-D.ietf-httpbis-http2-secondary-certs] 302 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 303 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 304 http2-secondary-certs-02 (work in progress), June 2018. 306 [I-D.ietf-tls-exported-authenticator] 307 Sullivan, N., "Exported Authenticators in TLS", draft- 308 ietf-tls-exported-authenticator-08 (work in progress), 309 October 2018. 311 [I-D.ietf-tls-subcerts] 312 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 313 "Delegated Credentials for TLS", draft-ietf-tls- 314 subcerts-02 (work in progress), August 2018. 316 [I-D.ietf-tls-tls13] 317 Rescorla, E., "The Transport Layer Security (TLS) Protocol 318 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 319 March 2018. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, . 326 10.2. Informative References 328 [I-D.irtf-cfrg-randomness-improvements] 329 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 330 and C. Wood, "Randomness Improvements for Security 331 Protocols", draft-irtf-cfrg-randomness-improvements-03 332 (work in progress), October 2018. 334 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 335 Proceedings of Euro S"P 2016 , 2016, 336 . 338 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 339 authenticated Diffie-Hellman and its use in the IKE 340 protocols", Proceedings of CRYPTO 2003 , 2003. 342 Authors' Addresses 344 Eric Rescorla 345 Mozilla 347 Email: ekr@rtfm.com 349 Nick Sullivan 350 Cloudflare 352 Email: nick@cloudflare.com 354 Christopher A. Wood 355 Apple Inc. 356 One Apple Park Way 357 Cupertino, California 95014 358 United States of America 360 Email: cawood@apple.com