On Thu, Feb 19, 2026 at 10:43:47AM +0530, tirumal reddy wrote: > This change updates the EKU key schedule to explicitly include the previous > transcript hash. This ensures that the new traffic keys are anchored to the > entire transcript history, providing full transcript continuity. While the > previous version had secret continuity through recursive chaining, it > lacked transcript continuity.
I do not think the rules in section 11.1 are sufficient to prevent cryptographic state ambiguity. Specifically, there is edge case where the EKU(key_update_request) and CertificateRequest cross (and there is no way to prevent that from happening). I think that could be handled by adding a third rule that if server receives EKU(key_update_request) while there is a pending certificate request, it MUST hold the EKU until the pending certificate requests clear. In DTLS, the client MUST be prepared to receive EKU(key_update_response) before acknowledgement for its reply. That can happen if packets get lost or reordered. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
