According to KeyCDN, TLSv1.3 connections are established in a single round trip:

While TLS 1.2 requires two round-trips to complete the TLS handshake, 1.3 gets the job done in just one trip

If that is the case, then the client's first message (after the TCP handshake) must include everything that the server will need for symmetric encryption, including the key and cipher suite. That means that the client would have to choose a suite without any input from the server.

How can the client be sure to pick a cipher suite that the server supports?

  • 1
    Take a look on this website, tls13.ulfheim.net – Mahdi Sedaghat Nov 26 at 5:52
  • 1
    @MahdiSedaghat That website is so helpful! So much more informative than staring at TCP dumps with unprintable characters... – Alex Nov 27 at 15:56
  • Exactly, this website also helps me a lot. Good luck. – Mahdi Sedaghat Nov 28 at 12:19
up vote 3 down vote accepted

The client doesn't - the server now chooses the ciphersuite. The client now sends the supported client suites and the server gets to choose. Fortunately there aren't that many ciphersuites for TLS 1.3 because the server is likely to have a somewhat shorter list (note that there are only two bytes required per cipher suite though).

Similarly, since there is only DHE and ECDHE for key agreement it is relatively easy to "guess" the key agreement protocol. It's pretty likely that a server supports both - and otherwise it just costs another round trip and key pair generation.

An even better explanation can be found here with clear indications of what gets send at what step in the communication between client / server. Note that "key share" here is not an encrypted key, it's just the public key of the generated ephemeral key pair.

  • I forgot that DHE results in both parties possessing the private key within one round trip! Also, I assume that, along with the certificate, the server signs its key share with the private key of its certificate? – Alex Nov 26 at 3:16
  • Are cipher suites tied to TLS versions? Is it something new to 1.3 or has been there for all along? I thought any cipher suite could work with any version of TLS. E.g. I know GCM related suites were introduced in 1.2, but thougt they could work with 1.1 as well. – Saptarshi Basu Nov 26 at 17:33
  • 1
    @SaptarshiBasu TLS 1.3 is a reboot of the TLS protocol. They've even considered calling it SSL 2 and a few other names (I voiced against that, because the drafts are already called TLS 1.3 and the name stuck). Because it is such a big rewrite, the way of handling ciphersuites has changed as well. – Maarten Bodewes Nov 26 at 20:08
  • 1
    @SaptarshiBasu: no, GCM (and other AEAD) suites require a new record format that doesn't exist in 1.1 or lower. Suites defined in any of SSL3-TLS1.1 can work technically in all of them and 1.2, although some were disallowed (Fortezza, then export, then single-DES, and IIRC IDEA). 1.3 uses (only) a new kind of suite that selects only symmetric cipher (always AEAD so no separate HMAC) and HKDF hash (replacing former PRF), but not keyexchange and authentication which are handled independently. – dave_thompson_085 Nov 27 at 3:44
  • 1
    @Alex: in 1.3 authentication always (server and if used client) signs a transcript hash, similar but not exactly the same as client auth did in 1.2 and below. See section 4.4 and specifically 4.4.1 and 4.4.3 of rfc8446 – dave_thompson_085 Nov 27 at 3:45

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.