On Tue, Nov 05, 2024 at 03:24:16PM +0000, David Benjamin wrote: > On Tue, Nov 5, 2024 at 2:25 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > There is WG draft for Extended Key Update. That can be initiated from > > either side, needs at least three flights (and the current version has > > four flights) and prepares epcoh changes. Basically hits every edge case > > there is. > > > > Oh yeah, KeyUpdate as specified in RFC 9147 is completely broken. I started > a thread about it back in > https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/
Ugh, yeah, that is broken (the same-epoch requirement messes things). Why is the same-epoch requirement there? I get that it is important that the handshake messages get sent with correct epoch, but there is obvious reason to keep epoch with post-handshake messages. That is of course other than those that prepare epoch change, but there can only be one in epoch, and all prior flights must be complete before the actual epoch change. > > What if the past flight has reply? Unless one has got an (implicit) ACK > > from the other side about the reply, retransmission on flight signals to > > retransmit the reply. > > > > E.g., server sends CertificateRequest and 9 NSTs in parallel. Client > > insta-NAKs the CR, and ACKs all the NSTs. The NAK gets lost. Server > > re-transmits the CR. Now client has to resend the NAK from 9 flights > > back. > > > > Since any such reply must be pending flight, one could track the range > > of message sequences that trigger retransmit for pending flight. > > > (Guessing by NAK you mean replies with an empty Certificate message?) Right. > That is a good point. Until you've gotten the reply ACKed, you also need to > store enough information to reconstruct that. Yet more things that RFC 9147 > should be spelling out. > > Actually, for that matter, what ensures that the multi-message flights in a > post-handshake transaction are consecutive? AFAICT, that requirement gets inherited from TLS 1.3. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
