Subject: [quicwg/base-drafts] Server might be unable to complete handshake due to MAX_STREAM_DATA (#725)

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Aug 2017 10:28:23 +0000 (UTC)

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.

-- 
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/725

---

From: janaiyengar <[email-masked]>
Date: Tue, 15 Aug 2017 00:21:27 +0000 (UTC)

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?

-- 
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/725#issuecomment-322344581

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 17:36:13 -0700

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.

-- 
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/725#issuecomment-322346449

---

From: MikkelFJ <[email-masked]>
Date: Tue, 15 Aug 2017 01:53:56 -0700

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?

-- 
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/725#issuecomment-322415959

---

From: Mike Bishop <[email-masked]>
Date: Tue, 15 Aug 2017 16:09:26 +0000 (UTC)

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?

-- 
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/725#issuecomment-322512533

---

From: Mike Bishop <[email-masked]>
Date: Tue, 15 Aug 2017 16:15:19 +0000 (UTC)

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.)

-- 
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/725#issuecomment-322513965