idnits 2.17.1 draft-rescorla-tls13-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 (March 05, 2018) is 2245 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: 'RFC2119' is defined on line 314, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-curdle-pkix-07 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-00 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 Summary: 2 errors (**), 0 flaws (~~), 6 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: September 6, 2018 Cloudflare 6 March 05, 2018 8 Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 9 draft-rescorla-tls13-semistatic-dh-00 11 Abstract 13 TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman 14 exchange modelled after SIGMA [SIGMA]. This design is suitable for 15 endpoints whose certified credential is a signing key, which is the 16 common situation for current TLS servers. This document describes a 17 mode of TLS 1.3 in which one or both endpoints have a certified DH 18 key which is used to authenticate the exchange. 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 http://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 September 6, 2018. 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 (http://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 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Certificate Format . . . . . . . . . . . . . . . . . . . . . 5 58 5. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Certificate Verify Computation . . . . . . . . . . . . . 5 60 5.2. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 62 7. 0-RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 10.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 DISCLAIMER: This is a work-in-progress draft and is currenty totally 73 handwavy, so it has not yet seen significant security analysis. It 74 should not be used as a basis for building production systems. 76 TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman 77 exchange modelled after SIGMA [SIGMA]. This design is suitable for 78 endpoints whose certified credential is a signing key, which is the 79 common situation for current TLS servers, which is why it was 80 selected for TLS 1.3. 82 However, it is also possible - although currently rare - for 83 endpoints to have a credential which is an (EC)DH key. This can 84 happen in one of two ways: 86 o They may be issued a certificate with an (EC)DH key, as specified 87 for instance in [I-D.ietf-curdle-pkix] 89 o They may have a signing key which they use to generate a delegated 90 credential [I-D.ietf-tls-subcerts] containing an (EC)DH key. 92 In these situations, a signed DH exchange is not appropriate, and 93 instead a design in which the server authenticates via its long-term 94 (EC)DH key is suitable. This document describes such a design 95 modelled on that described in OPTLS [KW16]. 97 This design has a number of potential advantages over the signed 98 exchange in TLS 1.3, specifically: 100 o If the end-entity certificate contains an (EC)DH key, TLS can 101 operate with a single asymmetric primitive (Diffie-Hellman). The 102 PKI component will still need signatures, but the TLS stack need 103 not have one. Note that this advantage is somewhat limited if the 104 (EC)DH key is in a delegated credential, but that allows for a 105 clean transition to (EC)DH certificates. 107 o It is more resistant to random number generation failures on the 108 server because the attacker needs to have both the server's long- 109 term (EC)DH key and the ephemeral (EC)DH key in order to compute 110 the traffic secrets. [Note: 111 [I-D.cremers-cfrg-randomness-improvements] describes a technique 112 for accomplishing this with a signed exchange.] 114 o If the server has a comparatively slow signing cert (e.g., P-256) 115 it can amortize that signature over a large number of connections 116 by creating a delegated credential with an (EC)DH key from a 117 faster group (e.g., X25519). 119 o Because there is no signature, the server has deniability for the 120 existence of the communication. Note that it could always have 121 denied the contents of the communication. 123 This exchange is not generally faster than a signed exchange if 124 comparable groups are used. In fact, if delegated credentials are 125 used, it may be slower on the client as it has to validate the 126 delegated credential, though this operation is cacheable. 128 2. Protocol Overview 130 The overall protocol flow remains the same as that in ordinary TLS 131 1.3, as shown below: 133 Client Server 135 Key ^ ClientHello 136 Exch | + key_share* 137 | + signature_algorithms* 138 | + psk_key_exchange_modes* 139 v + pre_shared_key* --------> 140 ServerHello ^ Key 141 + key_share* | Exch 142 + pre_shared_key* v 143 {EncryptedExtensions} ^ Server 144 {CertificateRequest*} v Params 145 {Certificate*} ^ 146 {CertificateVerify*} | Auth 147 {Finished} v 148 <-------- [Application Data*] 149 ^ {Certificate*} 150 Auth | {CertificateVerify*} 151 v {Finished} --------> 152 [Application Data] <-------> [Application Data] 154 As usual, the client and server each supply an (EC)DH share in their 155 "key_share" extensions. However, in addition, the server supplies a 156 static (EC)DH share in its Certificate message, either directly in 157 its end-entity certificate or in a delegated credential. The client 158 and server then perform two (EC)DH exchanges: 160 o Between the client and server "key_share" values to form an 161 ephemeral secret (ES). This is the same value as is computed in 162 TLS 1.3 currently. 164 o Between the client's "key_share" and the server's static share, to 165 form a static secret (SS). 167 Note that this means that the server's static secret MUST be in the 168 same group as selected group for the ephemeral (EC)DH exchange. 170 The handshake then proceeds as usual, except that: 172 o Instead of containing a signature, the CertificateVerify contains 173 a MAC of the handshake transcript, computed based on SS. 175 o SS is mixed into the key schedule at the last HKDF-Extract stage 176 (where currently a 0 is used as the IKM input). 178 3. Negotiation 180 In order to negotiate this mode, we treat the (EC)DH MAC as if it 181 were a signature and negotiate it with a set of new signature scheme 182 values: 184 enum { 185 sig_p256(0x0901), 186 sig_p384(0x0902), 187 sig_p521(0x0903), 188 sig_x52219(0x0904), 189 sig_x448(0x0905), 190 } SignatureScheme; 192 When present in the "signature_algorithms" extension or 193 CertificateVerify.signature_scheme, these values indicate DH MAC with 194 the specified key exchange mode. These values MUST NOT appear in 195 "signature_algorithms_cert". 197 Before sending and upon receipt, endpoints MUST ensure that the 198 signature scheme is consistent with the ephemeral (EC)DH group in 199 use. 201 4. Certificate Format 203 Like signing keys, static DH keys are carried in the Certificate 204 message, either directly in the EE certificate, or in a delegated 205 credential. In either case, the OID for the SubjectPublicKeyInfo 206 MUST be appropriate for use with (EC)DH key establishment. If in a 207 certificate, the key usage and EKU MUST also be set appropriately See 208 [I-D.ietf-curdle-pkix] and [[TBD: P-256, etc.]] for specific details 209 about these formats. 211 5. Cryptographic Details 213 5.1. Certificate Verify Computation 215 Instead of a signature, the server proves knowledge of the private 216 key associated with its static share by computing a MAC over the 217 handshake transcript using SS. The transcript thus far includes all 218 messages up to and including Certificate, i.e.: 220 Transcript-Hash(Handshake Context, Certificate) 222 The MAC key - SS-Base-Key - is derived from SS as follows: 224 SS-Base-Key = HKDF-Extract(0, SS) 226 The MAC is then computed using the Finished computation described in 227 [I-D.ietf-tls-tls13] Section 4.4, with SS-Base-Key as the Base Key 228 value. Receivers MUST validate the MAC and terminate the handshake 229 with a "decrypt_error" alert upon failure. 231 Note that this means that the server sends two MAC computations in 232 the handshake, one in CertificateVerify using SS and the other in 233 Finished using the Master Secret. These MACs serve different 234 purposes: the first authenticates the handshake and the second proves 235 possession of the ephemeral secret. [[OPEN ISSUE: Verify that this 236 is OK because neither MAC is computed with the mixed key. At least 237 one version of OPTLS was somewhat like that, however.]] 239 5.2. Key Schedule 241 The final HKDF-Extract stage of the TLS 1.3 key schedule has an HKDF- 242 Extract with the IKM of 0. When static key exchange is negotiated, 243 that 0 is replaced with SS, as shown below. 245 ... 246 Derive-Secret(., "derived", "") 247 | 248 v 249 SS -> HKDF-Extract = Master Secret 250 | 251 +-----> Derive-Secret(., "c ap traffic", 252 | ClientHello...server Finished) 253 | = client_application_traffic_secret_0 254 | 255 ... 257 6. Client Authentication 259 [[OPEN ISSUE]] In principle, we can do client authentication the same 260 way, with the client's DH key in Certificate and a MAC in 261 CertificateVerity. However, it's less good because the client's 262 static key doesn't get mixed in at all. Also, client DH keys seem 263 even further off. 265 7. 0-RTT 267 [[OPEN ISSUE]] It seems like one ought to be able to publish the 268 server's static key and use it for 0-RTT, but actually we don't know 269 how to do the publication piece, so I think we should leave this out 270 for now. 272 8. Security Considerations 274 [[OPEN ISSUE: This is a -00, so the security considerations are kind 275 of sketchy.]] 277 o This is intended to have roughly equivalent security properties to 278 current TLS 1.3, except for the points raised in the introduction. 280 o There are open questions about how much key mixing we want to do, 281 especially with respect to client authentication. 283 o I'm not sure I like the double extract of SS. I've looked it over 284 and the SS-Base-Key and the HKDF-Extract to make the MS should be 285 independent, but I'd like to give it another look-over to see if 286 there is a cleaner way to do it. 288 9. IANA Considerations 290 IANA [SHOULD add/has added] the new code points specified in 291 Section 3 to the TLS 1.3 signature scheme registry, with a 292 "recommended" value of TBD. 294 10. References 296 10.1. Normative References 298 [I-D.ietf-curdle-pkix] 299 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 300 Ed25519, Ed448, X25519 and X448 for use in the Internet 301 X.509 Public Key Infrastructure", draft-ietf-curdle- 302 pkix-07 (work in progress), November 2017. 304 [I-D.ietf-tls-subcerts] 305 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 306 "Delegated Credentials for TLS", draft-ietf-tls- 307 subcerts-00 (work in progress), October 2017. 309 [I-D.ietf-tls-tls13] 310 Rescorla, E., "The Transport Layer Security (TLS) Protocol 311 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 312 March 2018. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, . 319 10.2. Informative References 321 [I-D.cremers-cfrg-randomness-improvements] 322 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 323 and C. Wood, "Randomness Improvements for Security 324 Protocols", draft-cremers-cfrg-randomness-improvements-00 325 (work in progress), March 2018. 327 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 328 Proceedings of Euro S"P 2016 , 2016, 329 . 331 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 332 authenticated Diffie-Hellman and its use in the IKE 333 protocols", Proceedings of CRYPTO 2003 , 2003. 335 Authors' Addresses 337 Eric Rescorla 338 Mozilla 340 Email: ekr@rtfm.com 342 Nick Sullivan 343 Cloudflare 345 Email: nick@cloudflare.com