TLS 1.3 HKDF-Expand references to Hello messages



  • I am looking into TLS 1.3 implementations and am a little confused about what is being referenced in the HKDF functions. Specifically the last argument in the Dervice_Secret wrapper function. From RFC 8446:

     PSK ->   = Early Secret
                 |
                 +-----> Derive-Secret(., "ext binder" | "res binder", "")
                 |                     = binder_key
                 |
                 +-----> Derive-Secret(., "c e traffic", ClientHello)
                 |                     = client_early_traffic_secret
                 |
                 +-----> Derive-Secret(., "e exp master", ClientHello)
                 |                     = early_exporter_master_secret
                 v
    

    In this example ClientHello is the argument; however, it is unclear what specifics bytes that refers to:

    • It is the whole client hello message?
    • Is it just a field or extension in the hello message? like ClientHello.random?


  • The Derive-Secret function is defined this way in § 7.1:

    Derive-Secret(Secret, Label, Messages) =
         HKDF-Expand-Label(Secret, Label,
                           Transcript-Hash(Messages), Hash.length)
    

    § 4.4.1 specifies that the transcript hash is generally just the hash of the messages concatenated (although there is an exception), so in this case, it's a hash of the entire message. Specifically:

    This value is computed by hashing the concatenation of each included handshake message, including the handshake message header carrying the handshake message type and length fields, but not including record layer headers.

    TLS 1.3 specifically uses the transcript hash in many cases because it foils certain techniques that could be used to cause different sessions to derive the same secrets. These had been used in attacks on the protocol in the past, and they were also used by MITM devices in the past. Since the only way now to derive identical secrets is to perform an identical key exchange and we assume the attacker doesn't know the key exchange private key, these attacks are no longer possible.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2