idnits 2.17.00 (12 Aug 2021) /tmp/idnits25073/draft-ietf-tls-semistatic-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([SIGMA], [RFC8446]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '... server's static secret MUST be in the...' RFC 2119 keyword, line 187: '...mode. These values MUST NOT appear in...' RFC 2119 keyword, line 190: '...eceipt, endpoints MUST ensure that the...' RFC 2119 keyword, line 192: '... use. Clients MUST NOT advertise si...' RFC 2119 keyword, line 200: '...ectPublicKeyInfo MUST be appropriate f...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (7 March 2020) is 798 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) == Outdated reference: draft-ietf-curdle-pkix has been published as RFC 8410 == Outdated reference: A later version (-13) exists of draft-ietf-tls-subcerts-06 Summary: 3 errors (**), 0 flaws (~~), 4 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: 8 September 2020 Cloudflare 6 C.A. Wood 7 Apple Inc. 8 7 March 2020 10 Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 11 draft-ietf-tls-semistatic-dh-01 13 Abstract 15 TLS 1.3 [RFC8446] specifies a signed Diffie-Hellman exchange modelled 16 after SIGMA [SIGMA]. This design is suitable for endpoints whose 17 certified credential is a signing key, which is the common situation 18 for current TLS servers. This document describes a mode of TLS 1.3 19 in which one or both endpoints have a certified DH key which is used 20 to authenticate the exchange. 22 Note to Readers 24 Source for this draft and an issue tracker can be found at 25 https://github.com/ekr/draft-rescorla-tls13-semistatic-dh 26 (https://github.com/ekr/draft-rescorla-tls13-semistatic-dh). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 8 September 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Certificate Format . . . . . . . . . . . . . . . . . . . . . 5 65 5. Certificate Verify Computation . . . . . . . . . . . . . . . 5 66 6. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 9.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 DISCLAIMER: This is a work-in-progress draft and has not yet seen 77 significant security analysis. Thus, this draft should not be used 78 as a basis for building production systems. 80 TLS 1.3 [RFC8446] specifies a signed Diffie-Hellman (DH) exchange 81 modeled after SIGMA [SIGMA]. This design is suitable for endpoints 82 whose certified credential is a signing key, which is the common 83 situation for current TLS servers, which is why it was selected for 84 TLS 1.3. 86 However, it is also possible - although currently rare - for 87 endpoints to have a credential which is an (EC)DH key. This can 88 happen in one of two ways: 90 * They may be issued a certificate with an (EC)DH key, as specified 91 for instance in [I-D.ietf-curdle-pkix] 93 * They may have a signing key which they use to generate a delegated 94 credential [I-D.ietf-tls-subcerts] containing an (EC)DH key. 96 In these situations, a signed DH exchange is not appropriate, and 97 instead a design in which the endpoint authenticates via its long- 98 term (EC)DH key is suitable. This document describes such a design 99 modeled on that described in OPTLS [KW16]. 101 This design has a number of potential advantages over the signed 102 exchange in TLS 1.3, specifically: 104 * If the end-entity certificate contains an (EC)DH key, TLS can 105 operate with a single asymmetric primitive (Diffie-Hellman). The 106 PKI component will still need signatures, but the TLS stack need 107 not have one. Note that this advantage is somewhat limited if the 108 (EC)DH key is in a delegated credential, but that allows for a 109 clean transition to (EC)DH certificates. 111 * If the endpoint has a comparatively slow signing cert (e.g., 112 P-256) it can amortize that signature over a large number of 113 connections by creating a delegated credential with an (EC)DH key 114 from a faster group (e.g., X25519). 116 * Because there is no signature, the endpoint has deniability for 117 the existence of the communication. Note that it could always 118 have denied the contents of the communication. 120 This exchange is not generally faster than a signed exchange if 121 comparable groups are used. In fact, if delegated credentials are 122 used, it may be slower on the client as it has to validate the 123 delegated credential, though the result may be cached. 125 2. Protocol Overview 127 The overall protocol flow remains the same as that in ordinary TLS 128 1.3, as shown below: 130 Client Server 132 Key ^ ClientHello 133 Exch | + key_share* 134 | + signature_algorithms* 135 | + psk_key_exchange_modes* 136 v + pre_shared_key* --------> 137 ServerHello ^ Key 138 + key_share* | Exch 139 + pre_shared_key* v 140 {EncryptedExtensions} ^ Server 141 {CertificateRequest*} v Params 142 {Certificate*} ^ 143 {CertificateVerify*} | Auth 144 {Finished} v 145 <-------- [Application Data*] 146 ^ {Certificate*} 147 Auth | {CertificateVerify*} 148 v {Finished} --------> 149 [Application Data] <-------> [Application Data] 151 As usual, the client and server each supply an (EC)DH share in their 152 "key_share" extensions. However, in addition, the server supplies a 153 (signed) static (EC)DH share in its Certificate message, either 154 directly in its end-entity certificate or in a delegated credential. 155 The client and server then perform two (EC)DH exchanges: 157 * Between the client and server "key_share" values to form an 158 ephemeral secret (ES). This is the same value as is computed in 159 TLS 1.3 currently. 161 * Between the client's "key_share" and the server's static share, to 162 form a static secret (SS). 164 Note that this means that the server's static secret MUST be in the 165 same group as selected group for the ephemeral (EC)DH exchange. 167 The handshake then proceeds as usual, except that instead of 168 containing a signature, the CertificateVerify contains a MAC of the 169 handshake transcript, computed based on SS. 171 3. Negotiation 173 In order to negotiate this mode, we treat the (EC)DH MAC as if it 174 were a signature and negotiate it with a set of new signature scheme 175 values: 177 enum { 178 sig_p256(0x0901), 179 sig_p384(0x0902), 180 sig_p521(0x0903), 181 sig_x52219(0x0904), 182 sig_x448(0x0905), 183 } SignatureScheme; 185 When present in the "signature_algorithms" extension or 186 CertificateVerify.signature_scheme, these values indicate DH MAC with 187 the specified key exchange mode. These values MUST NOT appear in 188 "signature_algorithms_cert". 190 Before sending and upon receipt, endpoints MUST ensure that the 191 signature scheme is consistent with the ephemeral (EC)DH group in 192 use. Clients MUST NOT advertise signature scheme values that are 193 inconsistent with the "named_groups" extension they offer. 195 4. Certificate Format 197 Similar to signing keys, static DH keys are carried in the 198 Certificate message, either directly in the EE certificate, or in a 199 delegated credential. In either case, the OID for the 200 SubjectPublicKeyInfo MUST be appropriate for use with (EC)DH key 201 establishment. If in a certificate, the key usage and EKU MUST also 202 be set appropriately. See [I-D.ietf-curdle-pkix] for specific 203 details about these formats. 205 5. Certificate Verify Computation 207 Instead of a signature, the server proves knowledge of the private 208 key associated with its static share by computing a MAC over the 209 handshake transcript using SS. The transcript thus far includes all 210 messages up to and including Certificate, i.e.: 212 Transcript-Hash(Handshake Context, Certificate) 214 The MAC key, xSS, is derived from SS as follows: 216 xSS = HKDF-Extract(0, SS) 218 The MAC is then computed using the Finished computation described in 219 [RFC8446] Section 4.4, with xSS as the Base Key value. Receivers 220 MUST validate the MAC and terminate the handshake with a 221 "decrypt_error" alert upon failure. 223 Note that this means that the server sends two MAC computations in 224 the handshake, one in CertificateVerify using SS and the other in 225 Finished using the Master Secret. These MACs serve different 226 purposes: the first authenticates the handshake and the second proves 227 possession of the ephemeral secret. 229 6. Client Authentication 231 Client authentication works similar to that of server authentication 232 described in Section 2. In particular, servers indicate support of 233 semi-static keys by sending one of the relevant SignatureScheme 234 values defined in Section 3 inside the CertificateRequest 235 "signature_algorithms" extension. If applicable, clients reply with 236 a non-empty Certificate message carrying a corresponding certificate 237 with static DH key matching the chosen signature algorithm. Clients 238 then also compute the CertificateVerify message using the procedure 239 of Section 5, over the transcript hash Handshake Context described in 240 [RFC8446], Section 4.4. 242 If no matching certificate is available, clients send an empty 243 Certificate message as per [RFC8446]; Section 4.4.2. 245 7. Security Considerations 247 [[OPEN ISSUE: This design requires formal analysis.]] 249 This is intended to have roughly equivalent security properties to 250 current TLS 1.3, except for the points raised in the introduction. 252 Open questions: 254 * Should semi-static key shares be mixed into the key schedule? 256 8. IANA Considerations 258 IANA [SHOULD add/has added] the new code points specified in 259 Section 3 to the TLS 1.3 signature scheme registry, with a 260 "recommended" value of TBD. 262 9. References 264 9.1. Normative References 266 [I-D.ietf-curdle-pkix] 267 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 268 Ed25519, Ed448, X25519 and X448 for use in the Internet 269 X.509 Public Key Infrastructure", Work in Progress, 270 Internet-Draft, draft-ietf-curdle-pkix-10, 8 May 2018, 271 . 274 [I-D.ietf-tls-subcerts] 275 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 276 "Delegated Credentials for TLS", Work in Progress, 277 Internet-Draft, draft-ietf-tls-subcerts-06, 5 February 278 2020, . 281 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 282 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 283 . 285 9.2. Informative References 287 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 288 Proceedings of Euro S"P 2016 , 2016, 289 . 291 [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to 292 authenticated Diffie-Hellman and its use in the IKE 293 protocols", Proceedings of CRYPTO 2003 , 2003. 295 Authors' Addresses 297 Eric Rescorla 298 Mozilla 300 Email: ekr@rtfm.com 302 Nick Sullivan 303 Cloudflare 305 Email: nick@cloudflare.com 307 Christopher A. Wood 308 Apple Inc. 310 Email: cawood@apple.com