Re: [quicwg/base-drafts] Bound 0-to-1-RTT Transition (#2466)

[Kazuho Oku <[e-mail]>]

@DavidSchinazi Spec-wise, my view is that we should recommend (or at least state that it's possible for) servers can enforce TP-values of previous TLS connection for 0-RTT packets, because not doing so means that the threat model of 0-RTT in QUIC will be different from that of TLS 1.3.

TLS 1.3 uses `max_early_data_size` field of NewSessionTicket message to cap the amount of application data the client is allowed to send in 0-RTT. And we have already built things around it. For example, [RFC 8470 section 3](https://tools.ietf.org/html/rfc8470#section-3) states, quote: _A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for requests that it might defer until the handshake completes._

Unless we provide a mechanism to replace the function that replaces `max_early_data_size` in QUIC, not only HTTP but every application protocol will be required to have different security considerations for using 0-RTT of TLS 1.3 and QUIC.

And implementation-wise, I think H2O/quicly might implement this due to the following reasons:
* H2O/quicly buffers requests that were deemed to early, instead of forwarding 425 to the client. Therefore we have memory pressure caused by 0-RTT stream data. That needs to be capped.
* It is after the HEADERS frame for the 0-RTT request is read out from the receive buffer that H2O receives a 425 from upstream. That means that we cannot rely on transport-level back pressure to avoid the peer sending additional data.

My understanding is that this type of implementation (i.e. buffering requests deemed to early, reading out HEADERS frame from receive buffer) is something we expect to see, and therefore it'd be unsurprising to see others also enforcing the limit.

-- 
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/pull/2466#issuecomment-464255236