[quicwg/base-drafts] Two CHs handling the same SH (#4090)

[ekr <[e-mail]>]

Over in TLS, Mike Bishop posits the following scenario:

> The client sends an Initial packet (randomly selected Destination CID), PTOs, then sends another Initial packet to the same Destination CID.  On the server side, the infrastructure assumes that Initial packets whose CIDs aren’t issued by them can be routed to a random back-end, and that back-end will set a new DCID that routes to it in the future.

> The client will receive either of the Server Initial packets, switch to the new DCID, and will reject the other because attempts to change the server’s CID a second time.  The connection succeeds because whichever server’s ServerHello is used also has its DCID used, so all subsequent packets go to that back-end.

https://mailarchive.ietf.org/arch/msg/tls/O5jDgpPyQ_BSIz8_LXmD5rbOHnw/

My response:

> While it's not clear to me that QUIC explicitly prohibits this (it would be prohibited if CRYPTO frames were STREAM frames because of draft-ietf-tls-quic-transport S 2.2, it seems like it's  quite bad practice because the result will be that the losing server has a pending handshake which it continues to retransmit on until the client times out.

Is this in fact possible? Should we forbid it?





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4090