On Mon, Feb 23, 2026 at 04:38:32PM +0530, tirumal reddy wrote: > On Mon, 23 Feb 2026 at 13:07, Ilari Liusvaara <[email protected]> > wrote: > > > 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.
The scenario is: 1) Server sends CertificateRequest 2) (The packet got dropped.) 3) The server receives EKU request. 4) The server notices that the packet got dropped. 5) The server MUST retransmit the CertificateRequest. And no, deferring that retransmission is not an option. The CR MUST be sent before sending the EKU reply. Anything else breaks DTLS. > 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). It is very nontrivial to defer processing (TLS-level) post-handshake authentication due to handshake transcript continuity. And deferring processing Exported Authenticators is not possible at all — nor is it possible to defer processing EKU for EA. And it is also nontrivial to use post-handshake authentication or EA for EKU MITM detection. The problem is that both mechanisms send a new certificate, and matching the identity with existing one is much harder than it seems. For example, this the major reason TLS 1.2 renegotiation is banned in HTTP/2 (RFC 7540, section 9.2.1). -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
