On Thu, 19 Feb 2026 at 14:23, Ilari Liusvaara <[email protected]> wrote:
> 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. > If EKU is held, post-handshake authentication has to be re-triggered immediately after EKU completion to detect any divergence resulting from interference during the EKU exchange. It is a better option to hold the CertificateRequest until EKU exchange is complete. > > 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. > EKU(key_update_response) implicitly acknowledges EKU(key_update_request). ACK is only sent when the peer is deferring. key_update_response and ACK message can be received out of order; late ACK needs to be ignored. -Tiru > > > > > -Ilari > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
