idnits 2.17.1 draft-bzwu-tls-client-keyshare-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 125 has weird spacing: '...edGroup gro...' -- The document date (May 5, 2015) is 3278 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) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 178, but not defined ** Obsolete normative reference: RFC 5077 (ref. 'TICKET') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (ref. 'TLSBCP') (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 4492 (ref. 'TLSECC') (Obsoleted by RFC 8422) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS BZ. Wu 3 Internet-Draft Alibaba Inc. 4 Intended status: Standards Track May 5, 2015 5 Expires: November 6, 2015 7 Transport Layer Security (TLS) Client Keyshare Extension 8 draft-bzwu-tls-client-keyshare-01 10 Abstract 12 This document defines an extension that allows a TLS client to carry 13 Diffie-Hellman (DH) keyshares in ClientHello message, replacing the 14 ClientKeyExchange message in the second round-trip, to reduce the 15 full handshake latency to one network round-trip time (RTT). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 6, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 53 3. Client Keyshare Extension . . . . . . . . . . . . . . . . . . 3 54 3.1. Extension Type . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Extension-data Specification . . . . . . . . . . . . . . 3 56 3.3. Message Flow with This Extension . . . . . . . . . . . . 4 57 4. Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 A full TLS handshake as specified in [TLSv1.2] requires 2-RTT, mostly 67 because of the ClientKeyExchange message in the second round-trip, 68 which is used for the key exchange. TLS 1.3, which works in 69 progress, will offer a 1-RTT mode by sending DH keyshare immediately 70 after the ClientHello in the first round-trip, called ClientKeyShare 71 message. However, it will take a long time to finalize the draft and 72 deploy TLS 1.3. 74 This document defines a TLS extension that allows a client using TLS 75 1.2 to carry DH keyshares in the ClientHello message with the first 76 round-trip. The client and server complete key exchange by the 77 keyshares and native ServerKeyExchange message, thus the 78 ClientKeyExchange message is not necessary and could be omitted. 79 This leads to a latency reduction of one round-trip. 81 This extension is intended for TLS 1.2 only, but no previous versions 82 [TLSBCP]. This extension only supports Ephemeral DH, but no static 83 DH [TLSBCP]. This extension supports Elliptic Curve (EC) and Finite 84 Field (FF) keyshare types. Only NamedCurves [TLSECC] (for EC type) 85 and NegotiatedParameters (work in progress) (for FF type) are 86 supported, while generic parameters are not supported for safety and 87 simplicity. This extension dose not work if client certificates are 88 involved, which needs the second round-trip too. 90 2. Requirements Notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 96 3. Client Keyshare Extension 98 3.1. Extension Type 100 This document defines a new extension type (client_keyshare(TBD)), 101 which is used in the ClientHello and ServerHello messages. The 102 extension type is specified as follows. 104 enum { 105 client_keyshare(TBD), (65535) 106 } ExtensionType; 108 3.2. Extension-data Specification 110 The extension_data field of this extension, when included in the 111 ClientHello message, MUST contain the ClientKeyshare structure, which 112 offers one or more ClientKeyShareOffer values, each representing a 113 single set of DH key agreement parameters. The shares for each 114 ClientKeyShareOffer MUST be generated independently. Clients MUST 115 NOT offer multiple ClientKeyShareOffers for the same parameters. The 116 shares SHOULD keep the same order as with elliptic_curves extension 117 [TLSv1.2], to indicate client's preference. 119 struct { 120 ClientKeyShareOffer offers<0..2^16-1>; 121 } ClientKeyShare; 123 struct { 124 byte type(3); 125 NamedGroup group_id; 126 select (typeof(group_id)) { 127 case FF: ClientDiffieHellmanPublic; 128 case EC: ECPoint; 129 } public_key; 130 } ClientKeyShareOffer; 132 type 133 Since only NamedCurves and NegotiatedParameters are supported in 134 this extension, this byte exists only for compatibility with 135 ECCurveType in ECParameters [TLSECC], and its value MUST always be 136 3. 138 group_id 139 Specifies the DH parameters associated with the public key. 140 NamedGroup is extended from NamedCurve [TLSECC] by Negotiated 141 Finite Field Diffie-Hellman Ephemeral Parameters for TLS (work in 142 progress) to support finite-field-based DH. 144 public_key 145 The ephemeral DH public key. It's in ClientDiffieHellmanPublic 146 format [TLSv1.2] for FF type, or in ECPoint format [TLSECC] for EC 147 type. 149 Because the key exchange is made by the ClientKeyshare extension and 150 ServerKeyExchange message, it's not necessary to parse values in 151 extension_data if included in the ServerHello message. The server 152 just echoes the extension with an empty extension_data to indicate 153 support in the current this session. 155 3.3. Message Flow with This Extension 157 In brief, the full handshake works as follows with this extension. A 158 client takes this extension with some DH keyshares in the ClientHello 159 message. A server receiving this extension echoes it in the 160 ServerHello message to indicate support within this session and sends 161 a ServerKeyExchange to complete the key exchange (with the DH 162 keyshare in client's extension). Since there is no ClientKeyExchange 163 to wait for, the server sends no ServerHelloDone, but 164 ChangeCipherSpec and Finished message immediately, similar to an 165 abbreviated handshake flow. 167 The message flow is illustrated in the this figure. 169 Client Server 171 ClientHello --------> 172 {with client_keyshare extension} 173 ServerHello 174 Certificate* 175 ServerKeyExchange 176 [ChangeCipherSpec] 177 <-------- Finished 178 [ChangeCipherSpec] 179 Finished --------> 180 Application Data <-------> Application Data 182 This works only if client and server both support the extension. For 183 example, if a server which does not support this extension receives a 184 ClientHello message with this extension, the server MUST ignore it. 186 This extension only works if the negotiated key exchange algorithm is 187 Ephemeral Diffie-Hellman (FFDHE or ECDHE). Obviously, the client has 188 to send a ClientKeyExchange message after getting the server's 189 certificate if it is using RSA as key exchange. Thus it can not 190 benefit from this extension. Although the client may get server's 191 certificate before the handshake by the Cached Infomation extension 192 (work in progress), we do not support RSA key exchange for 193 simplicity. TLS 1.3 will remove support for RSA key-exchange 194 entirely and RSA as key-exchange is discouraged [TLSBCP] 196 Since the client does not know which DH types and parameters the 197 server supports, it MAY takes more than one DH keyshare in this 198 extension. The server picks one DH keyshare of the same type as with 199 the key exchange algorithm (FF or EC) and acceptable parameters, 200 generates a DH keyshare with the same parameters, sends it in 201 ServerKeyExchange message, and completes the key exchange with these 202 two keyshares. If there is no suitable keyshare in client's 203 extension, the server MUST ignore this extension. 205 A client enables this extension only if the server echoes this 206 extension in the ServerHello message. The client picks the 207 ClientKeyShareOffer containing the same parameters as with 208 ServerKeyExchange. If there is no such ClientKeyShareOffer, the 209 client MUST abort the handshake with an illegal_parameter fatal 210 alert. 212 If this extension is enabled, a server does not wait for the 213 ClientKeyExchange, or send a ServerHelloDone message; instead it 214 sends ChangeCipherSpec and Finished messages immediately, like with 215 an abbreviated handshake. Accordingly a client dose not send 216 ClientKeyExchange or wait for ServerHelloDone message. 218 A server does not enable this extension if it requests client's 219 certificate, which needs the second round-trip too. 221 Finally, this extension only works in full handshake, while not in 222 abbreviated handshake which does not need key exchange. 224 4. Interaction 226 Server sends ChangeCipherSpec and Finished messages after the 227 ServerKeyExchange, if this extension is enabled. However there may 228 be messages between the ServerKeyExchange and ChangeCipherSpec, e.g. 229 NewSessionTicket, if the Session Ticket extension is used [TICKET]. 231 With the Session Hash extension (work in progess) 232 "handshake_messages" refer to all handshake messages up to and 233 including the ClientKeyExchange message. There is no 234 ClientKeyExchange if this client_keyshare extension is enabled. The 235 "handshake_messages" should be changed to refer to all handshake 236 messages up to and including the ServerKeyExchange message, without 237 breaking the Session Hash extension. 239 5. Security Considerations 241 This extension brings client's DH keyshare forward, from the 242 ClientKeyExchange message in the second round-trip, to ClientHello 243 message in the first round-trip. TLS 1.3 (works in progress) also 244 works like this. So there should not be any security problem 245 introduced. 247 6. IANA Considerations 249 IANA is requested to add an entry to the existing TLS ExtensionType 250 registry, defined in TLS [TLSv1.2], for client_keyshare(TBD) defined 251 in this document. 253 7. Acknowledgements 255 Thanks to Ilari Liusvaara and Aaron Zauner for their valuable 256 comments and suggestions on this draft. 258 8. References 260 [KEYWORDS] 261 Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", RFC 2119, March 1997. 264 [TICKET] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 265 "Transport Layer Security (TLS) Session Resumption without 266 Server-Side State", RFC 5077, January 2008. 268 [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, 269 "Recommendations for Secure Use of Transport Layer 270 Security (TLS) and Datagram Transport Layer Security 271 (DTLS)", RFC 7525, May 2015. 273 [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 274 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 275 for Transport Layer Security (TLS)", RFC 4492, May 2006. 277 [TLSv1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security 278 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 280 Author's Address 282 Bingzheng Wu 283 Alibaba Inc. 285 EMail: bingzheng.wbz@alibaba-inc.com