Re: [quicwg/base-drafts] Flow control for post-handshake CRYPTO messages (#1834)

[David Benjamin <[e-mail]>]

Right, this issue originally came up as we were thinking through key availability vs key install times. The problem is, as you note, it's weird to allow sending data you cannot read ACKs for. (Conversely, it's weird, perhaps fatally so, to allow receiving data you cannot send ACKs for.) Though it's not the only scenario. The other side may send a burst of tickets.

> I'm very much inclined to leave this "unfixed", but to leave a warning that sending large post-handshake messages risks connection failure.

The point is that's not a sufficient warning. This is either a problem or a nitpick depending on the solution.

Sending an overly large message, in general, risks connection failure. TLS stacks bound the size there based on some ad-hoc analysis that no sane NewSessionTicket (or other message) will ever exceed such-and-such bytes based on what goes in it. TLS stacks typically buffer up a message before processing, so it makes sense that the TLS stack is responsible for buffering it.

But that's distinct from sending *many* post-handshake messages. TLS over QUIC must also account for that due to the lack of flow control. TLS over TCP does not have this problem because TCP provides flow control. If I try to send a million 100-byte TLS messages over TCP, I'll quickly run into TCP's flow control.

QUIC, however, doesn't have such flow control for CRYPTO frames. Instead it relies on a limit from the crypto protocol:
https://tools.ietf.org/html/draft-ietf-quic-transport-15#section-10.4

Although the TLS stack natively bounds *a single message* rather than *total data*, it is easy to compute a total limit during the handshake because there are only a fixed handful of messages. Thus the advice there works.... *except* for post-handshake messages. Thus the issue.

Realistically, it's probably fine to handwaive and say:
* The bound is not total data ever sent at the encryption level, but amount of data ahead of the read position.
* Pick some ad-hoc limit for post-handshake stuff, enough to fit a bunch of NSTs.
* Yeah, don't send too many NSTs in a row. You can send a bunch of them over the lifetime of the connection, but space them out a bit so you're sure the receiver isn't waiting on the first byte, having buffered the rest up.
* Probably you won't end up in a situation where the first NST packet keeps getting lost and as you queue up more and more NSTs over the lifetime of the connection. That would be strange.

-- 
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/1834#issuecomment-433239181