On Mon, Feb 23, 2026 at 11:19:04AM +0530, tirumal reddy wrote: > On Thu, 19 Feb 2026 at 14:23, Ilari Liusvaara <[email protected]> > wrote: > > > 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.
I do not think it is viable to hold CertificateRequest, because it is added to the transcript when sent/received, and thus binds the epoch at the time it is sent. And what I proposed might not be sufficient: In DTLS, there is also edge case where server MUST retransmit CertificateRequest in active EKU, since handshake messages can not be re-ordered. However, I do not think that mixing EKU and PHA actually leads into cryptographic state ambiguity. Since handshake messages can not be re-ordered, both sides always agree on epoch — stepped on response/ ack — CertificateRequest was sent in. However, implementing that logic might get annoying. > > 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. That was in reference to holding EKU for PHA: 1) Client and server cross EKU and certificate requests. 2) Client responds to certificate request. 3) Server acknowledges the client response, the packet is lost. 4) Server sends EKU response. 5) Client receives EKU response with unacknowledged certificate request response. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
