In TLS 1.3, is the Binder Key in a non-PSK derived key schedule always a consistent value?

Eddie

11/18/22, 7:38 PM

The Key Schedule in the TLS 1.3 RFC starts like this:

             0
             |
             v
   PSK ->  HKDF-Extract = 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
            ...

Later in Section 7.1, the RFC provides guidance on what to use as a substitute value for PSK if a Pre-Shared-Key is not actually used:

   If a given secret is not available, then the 0-value consisting of a
   string of Hash.length bytes set to zeros is used.  Note that this
   does not mean skipping rounds, so if PSK is not in use, Early Secret
   will still be HKDF-Extract(0, 0).

The client_early_traffic_secret and early_exporter_master_secret include a transcript hash of the Client Hello, which includes a Random Number generated by the client. So these two keys will be different for every SSL Session.

However, the binder_key does not include any transcript hash. Which means (by my interpretation), the only values feeding into the binder_key secret are both known by everyone and never change (0 as the starting value, 000...0 as the substitute for PSK, and the constant labels ext binder or res binder).

Am I interpreting that correctly? If so, how is this not a reduction in security that one of the output secret keys of the key schedule never changes?

1 + 0

tls

Score:1

Crypto

SAI Peregrinus

11/19/22, 1:10 PM

The binder key is used only for the PSK binder, which

forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established and the current session.

Without a previous session to establish a PSK, there's nothing to bind. There's no PSK to bind to the current handshake, and there's no previous session where the PSK was established. So the binder key is constant when not using a PSK, since it's only used to ensure that the client knows the same PSK that the server stored.

0 + 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: In TLS 1.3, is the Binder Key in a non-PSK derived key schedule always a consistent value?

TH: ใน TLS 1.3 Binder Key ในกำหนดการคีย์ที่ไม่ได้มาจาก PSK มีค่าที่สอดคล้องกันเสมอหรือไม่

RO: În TLS 1.3, cheia Binder într-un program de chei derivate non-PSK este întotdeauna o valoare consecventă?

RU: Всегда ли в TLS 1.3 ключ связывания в расписании ключей, не основанных на PSK, является согласованным значением?

VI: Trong TLS 1.3, Khóa liên kết trong lịch biểu khóa không phải PSK có nguồn gốc luôn là một giá trị nhất quán phải không?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.