Re: [TLS] TLS ECH, how much can the hint stick out?

[Eric Rescorla <[e-mail]>]

On Thu, Sep 10, 2020 at 2:21 PM Mike Bishop <[e-mail]> wrote:

> Certainly it’s better for the server if it can be consistent, especially
> if it expects multi-packet first flights.  If the same back-end sees both,
> it can discard the second, and that’s what I’d expect most of the time.
> But here’s what I think is possible:
>
>
>
> 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.
>

OK, this can't happen in DTLS because the CID management works differently.

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.

-Ekr