3
$\begingroup$

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?

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

1 Answer 1

3
$\begingroup$

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.

$\endgroup$
5
  • $\begingroup$ 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? $\endgroup$
    – ATLief
    Commented Nov 26, 2018 at 3:16
  • $\begingroup$ 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. $\endgroup$ Commented Nov 26, 2018 at 17:33
  • 1
    $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes
    Commented Nov 26, 2018 at 20:08
  • 1
    $\begingroup$ @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. $\endgroup$ Commented Nov 27, 2018 at 3:44
  • 1
    $\begingroup$ @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 $\endgroup$ Commented Nov 27, 2018 at 3:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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