Thanks Ilari for the detailed feedback, updated PR https://github.com/tlswg/tls-key-update/pull/96 to address the issue.
-Tiru On Mon, 23 Feb 2026 at 19:23, Ilari Liusvaara <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
