Hello Hosnieh,I am not an OpenSSL expert (and it may be the case that the key names used there are a source of confusion) but from specification perspective, I find your explanation of keys very confusing. Also, I am not sure what kind of /randomness/ you are looking for. Please see inline:
On 17.11.25 17:40, H.Rafiee wrote:
I am not sure why you call it "master key". Such a key name does not exist in TLS 1.3 specs (neither RFC8446 nor RFC8446bis). There was "Master secret" in RFC8446 which is now "Main secret" in RFC8446bis but that's a completely different key compared to PSK. And "Main secret" is generated very late in the key schedule, which seems irrelevant to your explanation.In short, TLS 1.3 uses 0-RTT to improve performance. To achieve this, it derives a key from the pre-shared key (PSK or master key)
What do you mean by "very simple way"? What in addition to HKDF-Extract were you expecting to generate Early Secret from PSK?, called the early secret (in OpenSSL). This early secret is derived in a very simple way
and is used for encrypting and authenticating the first communications.
That's actually not correct. Early Secret itself is never used except for generating three other keys via application of Derive-Secret in the first stage of derivation. One of those three keys is client_early_traffic_secret, which is then used to generate client_write_key via application of HKDF-Expand-Label in the second stage of derivation. client_write_key is the one used for encrypting 0-RTT data.
This is because the assumption is that PSK remains secret. Could you please clarify what do you mean by "system startup"? Are you resuming connections multiple times with the same PSK?The main concern is that this early secret is neither randomized nor changed after system startup.
For subsequent session keys, a static value is also used as input to the session key generation function, along with a few random values.
I am a bit lost in your terminology here. Which "static value"? Are you referring to the /label/ inputs for Derive-Secret?
Which "few random values"? Are you referring to the state of the handshake used as input in Derive-Secret? If so, there is nothing more than ClientHello available at the time when this key is generated, so I am not sure how one can add more "randomness".
As a result, the session key may not be sufficiently random.
Which "session key" exactly?
I don't think it's an issue but I may be missing something. Please provide answers to my questions.Questions to the community: Is this an OpenSSL implementation issue, or a protocol-level security problem? Were there any tests conducted for the protocol before its release? Is this issue already known?
Sure, if Early Secret is not protected, there is nothing preventing 0-RTT data. That is by design.Security risks: If there is a bug in the system or the early secret is not well protected in memory (it cannot be stored in an HSM or trusted environment because it needs to be readily available to TLS library), an attacker could reproduce or decrypt communication in case of vulnerabilities in one of the communicating systems.
Even if the TLS library uses isolated memory space, any bug in OpenSSL could expose the secret.
Same applies here.
Since the early secret lacks sufficient randomness, it seems necessary to change the PSK to prevent attackers from establishing secure communication.
Again, please clarify "randomness". Where would that random value be stored? Imagine somehow the randomness is there, if attacker has access to memory, can't it get that random value too?
Generally speaking, the role of the PSK is weak here. Even if it is well protected, as long as the early secret is poorly protected, knowing the early secret compromises the entire system.
Yes, that is by design. PSK-only does not have the same properties as the full handshake with ECDHE. In particular, losing Early Secret in PSK-only breaks all guarantees for 0-RTT data.
In general, you may find Section 1.3 in [0] helpful for general understanding of TLS key schedule.
-Usama[0] https://www.researchgate.net/publication/396245726_Perspicuity_of_Attestation_Mechanisms_in_Confidential_Computing_Validation_of_TLS_13_Key_Schedule
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
