On Mon, 23 Feb 2026 at 13:07, Ilari Liusvaara <[email protected]> wrote:
> 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. > For DTLS, if a CertificateRequest is received while EKU is active, it will be acknowledged as discussed in RFC 9147 Section 7.1. The ACK handles reliability, while the cryptographic processing of the authentication exchange is deferred until EKU completes. On holding CertificateRequest, the intent to defer its processing so that the authentication messages are computed only after EKU completes. This ensures that post-handshake authentication confirms the updated traffic secrets and exporter secret established by EKU and detects any divergence caused during the update (to detect MiTM attack). -Tiru > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
