6

TLS 1.3 specifies these three ciphersuites:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

all of them both feature authenticated cipher modes and and a hashing algorithm at the end. What is the purpose of these?

Philippe
  • 205
  • 2
  • 6

1 Answers1

9

While AES-GCM and ChaCha20-Poly1305 use AEAD cipher modes, and thus do not require a MAC on the encrypted data, there are still some parts of the TLS protocol which require a hash function.

The first is for handshake validation. When the Finished message is sent, it contains a hash of all the previous handshake messages sent, which allows TLS to validate that handshake messages sent before the key exchange weren't tampered with. The hash function used here is the one specified in the cipher suite. You can read about this in RFC 8446 Section 4.4.4.

The second is for key derivation. While the session master key is exchanged or agreed upon via ECDHE or a similar mechanism, this master key isn't directly used for encryption or authenticity verification. Instead, a PRF based on a HMAC is used to derive keys for various purposes (e.g. encryption), and the underlying hash of that HMAC is specified in the cipher suite. You can read about this in RFC8446 Appendix E.1.1 and in more detail in RFC 5246 Section 5.

Community
  • 1
Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • Out of scope for this question, but how do they establish the AES key if no key exchange mechanism is specified? – Mike Ounsworth Mar 15 '19 at 19:14
  • @MikeOunsworth TLS 1.3 only uses ECDHE so there's no reason to specify anything. – Polynomial Mar 15 '19 at 19:15
  • Ah, so ECDHE is implied in all TLS 1.3 cipher suites? – Mike Ounsworth Mar 15 '19 at 19:15
  • 2
    @MikeOunsworth Sort of. TLS 1.3 decoupled the key exchange mechanism from the cipher suite so it is now negotiated separately. ECDHE and DHE are supported but static RSA key exchange is gone. In the future TLS 1.3 might introduce alternative key exchange mechanisms but they won't be specified as part of the cipher suite itself. – Polynomial Mar 15 '19 at 19:21
  • 3
    As an aside, banking industry engineers and security middlebox vendors weren't very happy with the decision to remove static RSA key exchange, as it broke TLS inspection at the gateway in most existing appliances. They complained about it and the TLS working group [had some rather blunt things to say in response](https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA). So they banded together to [make a new protocol](https://xkcd.com/927/) and called it Enterprise TLS, which is literally just TLS 1.3 with static RSA added back in. It's terrible, don't use it. – Polynomial Mar 15 '19 at 19:27
  • I've already removed TLS 1.0, 1.1 and all ciphersuites without forward secrecy from my browsers. Half of the internet is broken now, but at least European banking industry is doing a lot better than Financial Services Roundtable members. – Esa Jokinen Mar 15 '19 at 19:50
  • 1
    Although (tweaked) HKDF serves mostly the same purposes in 1.3 as PRF did <= 1.2, it is a different function (and a different name); see 8446 #7 instead of 5246 #5. – dave_thompson_085 Mar 16 '19 at 08:28
  • 1
    One can look packet by packet analysis of TLS 1.3 handshake here https://tls13.ulfheim.net/ – Chits Jun 13 '19 at 15:33