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

[Martin Thomson <[e-mail]>]

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

> I had assumed that TLS stacks always expose the 1-RTT read key to the QUIC stacks acting as a server when it receives ClientFinished. I'd be curious to know if there are TLS stacks that takes an alternative approach.

That was what I had assumed too, until I thought through the nasty interactions with partial Handshake flights and 0-RTT.  That is, the TLS stack makes secrets available at the point that it would normally be installing them for its own use.  In that way, a server wouldn't install the 1-RTT read keys until it had processed the finished from the client, exactly as you say.

My current patch (which is still under review) releases secrets as soon as possible to avoid the problem where the server can't read Handshake acknowledgements because it is receiving 0-RTT.  The main consequence of that is that you need a separate API where the TLS stack tells the QUIC stack what it is willing to send and receive (well, I had a ton of fun fixing tests as well, but that's just because we were a little lazy with certain things in the past).

-- 
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-432911920