On 02.10.25 08:35, John Mattsson wrote:
I think almost everything _can_ be handled with extensions.
I would like to know what /exactly/ /cannot/ be handled with extensions?
To be clear, does that mean eliminating "PSK-only" or also "PSK with (EC)DHE"?- Require ephemeral key exchange in all cases.
- Require support for strong rekeying. TLS 1.3’s KeyUpdate is much weaker than the mechanisms in IPsec, SSH, and Signal and does not provide protection against key leakage.
There are several keys in TLS 1.3. Could you be specific about which "key leakage"? Specifically, did you mean client/server_application_traffic_secret?
Besides, could this not be accommodated in KeyUpdate draft?
- Avoid designing around HKDF and HMAC, which are only needed when the hash function has significant vulnerabilities/issues such as length-extension, failure to behave like a random function, lack of variable-length output, etc.
Extract-Expand paradigm using HKDF and HMAC is well-tested and formally verified. Could you clarify the advantage of avoiding this?
-Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
