Server might be unable to complete handshake due to MAX_STREAM_DATA

[martinthomson]

MAX_DATA doesn't apply to stream 0, but MAX_STREAM_DATA does. The server can increase the space available for the second flight of client handshake messages, but the client can't increase the space available to the server. The initial value (in the client's transport parameters) determines how much space the server has to send.

Is this a problem? should we exempt stream 0 (maybe just until the handshake completes)? or should we just advise against setting the value too low?

Note that the value is immutable, if a client wants a low value for general use, that might be a problem for the handshake. I'm inclined to say that stream 0 can exceed the limit up until the point that the handshake completes, after which the limit strictly applies. Then, if it has exceeded the limit, the server can't send anything until the client gives it more budget.

[janaiyengar]

I don't have a strong opinion on this. This surely is not a problem in practice, but we need to specify it for completeness. I'm leaning towards being conservative here. How about the server sends a CONNECTION_CLOSE with a CERT_TOO_LARGE error?

[martinthomson]

If it were only certificates, I'd be less worried. The potential and imminent need for post quantum key exchange, which generally has large keys, is what makes me concerned that this isn't purely theoretical. HANDSHAKE_TOO_LARGE maybe, but then we're left with a PQ problem to solve later.

[mikkelfj]

Taking the long term view - quantum computing, lattice encryption, more bandwidth: what is sensible today might not be tomorrow. A max limit could be implied by version, or it could unenforced but with a possible implemetation dependent error message. What are the possible scenarios of abuse?

[MikeBishop]

Obvious scenario for abuse: Client discovers a server with a large handshake, spoofs a source address, and launches an amplification attack at a target. Of course, such a malicious client would just give the server a nice, large flow control window to aid in the amplification attack, so that's slightly independent of the flow control limit. (That is, the attack wouldn't be worsened by loosening the bounds on Stream 0.)

I could see doing something like "If it can't fit in N times the size of the client's packet, server MUST do source address validation before performing the large handshake." However, that means we'll lose 0-RTT in post-quantum land, which makes me a little sad. Validating the address by pickling it in the 0-RTT ticket could partially fix this, but requires mitigations against the attacker capturing a valid ticket from the victim and replaying it many times. I think TLS 1.3 already suggests mitigations for this, doesn't it?

[MikeBishop]

Assuming the client's source is already validated, then the server sending as much as it can followed by a STREAM_BLOCKED frame seems reasonable. But the client's ability to respond is limited -- flow control frames in the subsequent "cleartext" client handshake packets are prohibited. (As they should be, since the packets at this stage can still be injected by an on-path attacker.)

[nibanks]

Has there been any more progress on this front? A coworker of mine suggested another thing that we should take into account: OCSP stapling. That would further increase the size of the server's payload.

I feel like, at least for v1, we should have a way to make progress in these scenarios, even if we lose out on 0-RTT. @MikeBishop's suggestion make sense:

"If it can't fit in N times the size of the client's packet, server MUST do source address validation before performing the large handshake."

But it doesn't fix the issue the server being blocked on the client's initial FC window. Maybe we always do a stateless retry if the server detects this issue and somehow communicates the minimum FC window size required in the retry?

[MikeBishop]

Exempting Stream 0 from stream flow control as well (until the handshake completes, or entirely) is probably the only real way out here. You'd still want the requirement to do address validation to keep that from becoming an attack vector, though.

[MikeBishop]

Closed by #1082, but GitHub apparently missed it.