Subject: [quicwg/base-drafts] RESET_STREAM should be allowed in 0-RTT packets (#2344)

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Jan 2019 19:23:06 -0800

[Section 4 of the TLS draft](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4) forbids a RESET_STREAM frame being sent in a 0-RTT packet.

I do not see a reason why we should prohibit that even though we allow FIN to be sent. RESET_STREAM is just another way of closing a stream. I think that we should allow RESET_STERAM to be sent using a 0-RTT packet.

FWIW, my assumption is that we simply missed to clarify that RST_STREAM is allowed when we split the frame into RST and STOP_SENDING.

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 17 Jan 2019 19:29:09 -0800

Do we really need any special rules for allowed frame types in 0-RTT packets? I don't see any justification for treating 0-RTT and 1-RTT different in that regard.

-- 
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/2344#issuecomment-455415793

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Jan 2019 20:02:38 -0800

@marten-seemann My understanding is that 0-RTT is a temporary state that provides less protection (i.e. not forward-secret and also replay-able). It makes sense to require clients to switch to 1-RTT ASAP. I think that the current approach of limiting the capability to the transmission of stream data is one way of accomplishing that.

-- 
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/2344#issuecomment-455420500

---

From: Benjamin Saunders <[email-masked]>
Date: Thu, 17 Jan 2019 20:10:27 -0800

If RESET_STREAM is to be permitted, shouldn't it also be permitted to send STOP_SENDING on locally initiated bidirectional streams?

-- 
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/2344#issuecomment-455421535

---

From: Marten Seemann <[email-masked]>
Date: Thu, 17 Jan 2019 21:07:12 -0800

I don't understand why we would consider e.g. flow control updates worthy of higher protection than application data.
Note that there's a real use case for sending flow control updates in 0-RTT packets: A client might anticipate a large response when it sends a request in 0-RTT request, and it can save one roundtrip by granting a lot of flow control credit for that response.

-- 
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/2344#issuecomment-455429150

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Jan 2019 21:45:36 -0800

@marten-seemann I'm not sure if that's true. A client can always use transport parameters to specify it's limits; I doubt if there's a benefit in updating the limits using a 0-RTT packet.

And in case of anticipating a large response, the anticipation would be that the transmission of the response would span across multiple round-trips (because of congestion control). Everything would work fine if the client's initial limit is large enough to cover what can be sent in the first round-trip (or several round-trips).

-- 
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/2344#issuecomment-455434688

---

From: Marten Seemann <[email-masked]>
Date: Thu, 17 Jan 2019 21:52:48 -0800

> @marten-seemann I'm not sure if that's true. A client can always use transport parameters to specify it's limits; I doubt if there's a benefit in updating the limits using a 0-RTT packet.

There's generally good reason to keep the initial window small, since we don't have any mechanism to update the transport parameters.

> And in case of anticipating a large response, the anticipation would be that the transmission of the response would span across multiple round-trips (because of congestion control). Everything woul…

That depends very much on the concrete values used.

> Asking for permission to send _BLOCKED frames in 0-RTT packets might make sense, though I am not sure if we'd need that in practice. I think we can expect a server allowing 0-RTT to provide enough window to let the client actually use 0-RTT.

Right, I hadn't even thought about BLOCKED. I think it proves my point here: If we don't allow those frame types in 0-RTT, we'll need *a lot* of special code just for keeping those frames out of 0-RTT packets (and to delay transmission until you have 1-RTT keys). Equivalently, on the receiver side, you'd need to implement checks that the payload of 0-RTT packets only contain valid frames. I don't see any reason for special casing anything here, so we should just allow all frame types in 0-RTT packets.

-- 
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/2344#issuecomment-455435788

---

From: Benjamin Saunders <[email-masked]>
Date: Thu, 17 Jan 2019 21:54:59 -0800

> And in case of anticipating a large response, the anticipation would be that the transmission of the response would span across multiple round-trips (because of congestion control). Everything woul…

I can imagine an application protocol oriented around using streams as message framing that might have small initial limits to support proportionately large numbers of in-flight streams, but occasionally request large responses by issuing MAX_STREAM_DATA alongside the request. Supporting such a pattern in 0-RTT seems useful.

-- 
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/2344#issuecomment-455436136

---

From: Nick Banks <[email-masked]>
Date: Fri, 18 Jan 2019 14:31:59 +0000 (UTC)

I agree with @marten-seemann. I think we should just have the same rules for 0-RTT and 1-RTT packets.

-- 
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/2344#issuecomment-455565154

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 18 Jan 2019 08:00:56 -0800

Acks cannot be sent in 0rtt packets atm, are you proposing changing that as well @marten-seeman

-- 
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/2344#issuecomment-455596181

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 18 Jan 2019 08:02:18 -0800

I’m on board with all other frame types though. I guess acks cannot logically be sent in 0rtt naturally, so maybe that’s not really a big deal

-- 
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/2344#issuecomment-455596633

---

From: MikkelFJ <[email-masked]>
Date: Fri, 18 Jan 2019 08:14:19 -0800

I agree that it makes sense to treat 0-RTT and 1-RTT the same since all frames the same. I'd still like to keep the handshake frames to the bare minimum.

-- 
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/2344#issuecomment-455600639

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Jan 2019 09:36:35 -0800

I agree with loosening the restrictions.  As with TLS 1.3, it's up to the application layer to restrict what things can't be done in 0-RTT.  Those should generally be things which have effects outside the connection itself, and at the QUIC layer, nothing the client sends does.

-- 
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/2344#issuecomment-455627562

---

From: MikkelFJ <[email-masked]>
Date: Fri, 18 Jan 2019 10:26:26 -0800

I have been skimming through the QUIC transport and QUIC TLS draft a few times. It is really difficult to decipher which frames can be sent where. Some packet types mention permitted frames in transport, but does not do that for all packet types. QUIC TLS has a list of frames for different packet types, but it is not clear if that cover all frame types.

QUIC TLS does suggest that CRYPTO frames can be sent in 1-RTT by stating the only 0-RTT cannot contain crypto, but is not clear about how or why that would happen, although I suspect it has to do with client auth - which is explicitly not permitted post handshake without any explanation. It could also be rekeying, but I think that is derived locally from session key.

-- 
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/2344#issuecomment-455642017

---

From: Benjamin Saunders <[email-masked]>
Date: Fri, 18 Jan 2019 18:28:23 +0000 (UTC)

> QUIC TLS does suggest that CRYPTO frames can be sent in 1-RTT by stating that only 0-RTT cannot contain crypto, but is not clear about how or why that would happen

This is useful for `NewSessionTicket`, for example.

-- 
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/2344#issuecomment-455642572

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 13:46:38 -0800

Bring the discussion back from #2355.  I'm thinking about @marten-seemann's comment there and I think that it would be easier if we were able to permit any frame type in 0-RTT (except CRYPTO, which has nothing to carry).

In thinking about this, the main concern is whether there is any replay risk associated with any of these frames.  Going through each, I didn't find anything.  Though replay does result in spurious state being created, it's all transient and connection-bound, not application state.  In general, all connection-level control messages affect only connection state, which goes away when the connection goes away.  And replayed 0-RTT always results in the connection being thrown out as the full handshake cannot successfully complete twice.

There might be some application-level significance to resetting streams in addition to carrying stream data, particularly when you consider the potential for selective replay.  An attacker with sufficient knowledge of the contents of packets could replay some packets and not others to effect changes.  But while the signals that a server application might receive are different, they are not outside of the range of possible signals that a client accepts as possible when sending the 0-RTT.  That is, if the server receives a partial stream rather than a complete stream, that is a potential outcome that the client has to accept as a possibility even when there is no attack.

If there are lasting application-layer effects from a RESET_STREAM (or STOP_SENDING), then this might cause problems.  But the application actively chooses to accept those risks by triggering these actions before the handshake is complete.

In addition, RESET_STREAM is a poor carrier for state-changing action because its semantics are better suited to abandoning state-changing effects, not creating them.  It would be a poor choice in protocol design to carry any application-layer signal with RESET_STREAM that implied a need for some action.  HTTP does this with CONNECT in a way, but that is only to match with a TCP RST and comes with no real expectation of it being reliable.

In the end, I conclude that we should permit all frames in 0-RTT and 1-RTT.  While there is some increased risk here, I think that this is best left to the 0-RTT profile for the protocol that uses QUIC.  For HTTP, where the only application-layer effect RESET_STREAM can have is to cancel requests, the result is to reduce exposure to replay.  Other protocols will need to make their own assessment about safety, but I don't anticipate problems.

I'll adjust #2355 to match.

-- 
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/2344#issuecomment-456206965

---

From: MikkelFJ <[email-masked]>
Date: Mon, 21 Jan 2019 15:58:58 -0800

I think this is an improvement but I am a bit anxious.

What happens to special frames related to connection migration that might affect a server view of a remembered client. What about tokens stored for future use - perhaps when looking towards v2 where things get more symmetrical. What about path migration and validation. What about 100 coalesced 0-RTT packets forcing 3x amp path validation, or something, in each - is that a possibility?

I like the simplicity of all frames - but black listing frames in a 0-RTT receive handler is not hard either - iff valid frames are clearly document. There could be a lot of hidden complexity in 0-RTT that we do not fully appreciate yet.

-- 
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/2344#issuecomment-456227919

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 21 Jan 2019 16:40:57 -0800

@martinthomson 
> In thinking about this, the main concern is whether there is any replay risk associated with any of these frames. Going through each, I didn't find anything. Though replay does result in spurious s…

The problem with 0-RTT in QUIC is that, unlike TLS 1.3 (that has max_early_data_size), there is no limit in the amount of data that the client can send using the 0-RTT key. IIUC, currently, it's entirely up to the client to decide when it switches from 0-RTT to 1-RTT keys.

As we know, Initial and 0-RTT packets can be replayed against different servers within a server cluster that does not (cannot) implement the use-only-once rule for the session tickets. I am concerned that widening how 0-RTT packets can be used might lead to additional exposure to the attack surface.

An attack would go like this:
1. an attacker creates a legitimate connection and obtains a session ticket
2. the attacker reconnects using the session ticket, and exchanges lots of information with the server (involving MAX_DATA, MAX_STREAMS, etc.). However, the attacker sticks to using 0-RTT for packets it emits, even after the handshake is complete.
3. simultaneously, the attacker creates many QUIC connections using the same Initial packet as that of step 2, and then sends the copied 0-RTT packets. The server will handle those and commit state. Because the client never responds with an 1-RTT ACK, the connection will eventually die. However, a client can create a connection with huge PTO (by delaying Initial packets) to have enough time to let the server accept many packets.

IMO it is preferable to allow less frames in 0-RTT packets, because it narrows the attack vector.

-- 
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/2344#issuecomment-456233537

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 17:27:51 -0800

@kazuho,

> The problem with 0-RTT in QUIC is that, unlike TLS 1.3 (that has max_early_data_size), there is no limit in the amount of data that the client can send using the 0-RTT key. IIUC, currently, it's en…

QUIC uses `initial_max_data` for that purpose.  You can't receive a flow control update, so whatever value you have for that determines how much 0-RTT you can send.

In thinking through this, I realized that the client can't send 0-RTT after receiving 1-RTT from the server.  A client won't have the keys until it has the entire handshake flight from the server, at which point it has to switch to 1-RTT keys.  So this all comes down to the same calculus we have in TLS/TCP, after you have spent a little bit of time on the question of RESET_STREAM and its effect on long-term application state.

-- 
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/2344#issuecomment-456240116

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 21 Jan 2019 17:46:27 -0800

@martinthomson 
> QUIC uses `initial_max_data` for that purpose. You can't receive a flow control update, so whatever value you have for that determines how much 0-RTT you can send.

My understanding is that an attacker acting as a client _can_ receive flow control updates (in 1-RTT packets), and use the updated value for emitting additional 0-RTT packets. Something like following:
* client obtains to a server and obtains session ticket and TP
* client reconnects, sends 0-RTT packets containing a STREAM frame (id=0, off=TP.initial_max_data-1, len=1)
* server sends handshake messages and a 1-RTT packet that contains MAX_DATA (maximum_data=TP.inital_max_data*3), because it observes the client reaching the limit
* client sends a _0-RTT_ packet containing a STREAM frame (id=0, off=TP.initial_max_data*3-1, len=1)
* server sends another 1-RTT packet containing MAX_DATA...
* client sends a _0-RTT_ packet containing a yet another STREAM frame...

-- 
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/2344#issuecomment-456243038

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 19:53:35 -0800

At the point the client has 1-RTT keys for receiving, it will have the ability to send using 1-RTT keys.  It can (and should) send its Finished too.  Why would it send with 0-RTT keys?

-- 
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/2344#issuecomment-456262901

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Jan 2019 11:11:52 -0800

Because the client here is an attacker.  However, I'm not seeing as much threat related to this specific change -- this is something the client can do regardless (generating many connections and causing state to be allocated for each).

So the attack here is to artificially create a large batch of (hopefully work-intensive) 0-RTT packets which are legitimate given a particular session ticket.  Then open a large set of parallel connections using the same session ticket and dump all those 0-RTT packets into each connection.

To guard against this, TLS 1.3 recommends [not accepting a given session ticket for multiple connections](https://tools.ietf.org/html/rfc8446#section-8.1).  This defense is the same for QUIC, and lives in the TLS layer.

-- 
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/2344#issuecomment-456525094

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 19:44:33 +0000 (UTC)

Is the concern here about a denial of service attack on the server?  That is, the extra frames that it might receive, which aren't really limited in any way by flow control or other such limitations, might cause it to do too much work?

This doesn't sound that interesting to me.  There is always a risk when you accept 0-RTT that the client or data is bad.  As @MikeBishop points out, you shouldn't be accepting the same 0-RTT multiple times.  The recommendations in TLS 1.3 provide some tips on how to avoid that.   But even if your server configuration doesn't allow you to detect that and stop it, the work you expend on 0-RTT packets is a cost that you take on.  And you take on that work with the understanding of the associated risk of replay.  Clients can always send far more stuff than you are prepared to process; servers just need to make the call.  For instance, rejecting 0-RTT would be my first response to increasing server load.

If a client chooses to send 0-RTT when 1-RTT keys are available to it, maybe we can allow servers to cut them off.  That's maybe hard to police, but simple things like exceeding initial flow control might be detectable.  Even if the server has provided more credit, the client should still be operating within the initial window for 0-RTT.

-- 
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/2344#issuecomment-456536446

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Jan 2019 11:49:09 -0800

I like that defense.  Just to sanity check, there shouldn't be a case in which the TLS handshake takes an extra round-trip _and_ 0-RTT is accepted, right?  Assuming that's true, saying that 0-RTT data MUST NOT exceed the initial connection flow control window (even if MAX_DATA frames are received in 1-RTT) and a pointer to the TLS 1.3 anti-replay protections seem like sufficient mitigation here.

-- 
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/2344#issuecomment-456537991

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 21:39:25 +0000 (UTC)

Correct.  TLS only takes an extra round trip with HelloRetryRequest, which results in 0-RTT being automatically rejected.

-- 
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/2344#issuecomment-456573625

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 22 Jan 2019 15:42:02 -0800

@MikeBishop 
> Because the client here is an attacker. However, I'm not seeing as much threat related to this specific change -- this is something the client can do regardless (generating many connections and cau…

The difference between a DoS using 1-RTT packets and 0-RTT packets is that the latter requires far less CPU cost on the attacker-side. This is because an attacker can just retransmit the same packets from different source tuples, whereas in 1-RTT case, an attacker needs to do expensive crypto operations (especially DH) for each connection it establishes.

Therefore my preference goes to limiting the capability of 0-RTT.

I like #2360 (maybe more than the approach I described in 
https://github.com/quicwg/base-drafts/pull/2355#pullrequestreview-194800021), because it clearly limits what a client can do using 0-RTT _for streams_.

The remaining question is what we should do for non-stream-related frames.

I still think that it makes sense to disallow the use of any non-stream-related frame in 0-RTT packets, considering the fact that:
* the frames allowed by 0-RTT and 1-RTT packets are nevertheless going to be different (CRYPTO, ACK)
* in practice there's no reason to send non-stream-related frames in 0-RTT packets
* potential security issues related to replay

-- 
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/2344#issuecomment-456608801

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 19:57:52 -0800

FWIW, I think that #2360 is about formalizing a poorly-enforced constraint that we might have assumed already existed.  It's not directly a solution to the problem were discussing.  I personally don't think that the cost of processing frames is significant enough to build additional defenses for.  Generic anti-DoS measures should suffice.

But clearly that's not a universally held viewpoint.  I think we should discuss this in Tokyo.  

-- 
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/2344#issuecomment-456661156

---

From: Marten Seemann <[email-masked]>
Date: Sat, 26 Jan 2019 00:08:50 -0800

If I understand our [rules for dropping keys](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#discarding-unused-keys) correctly, this attack is only possible for a limited amount of time, namely 3 PTO after the server received the Client Initial:
> For 0-RTT keys, which do not carry CRYPTO frames, this timer starts when the first packets protected with 1-RTT are sent or received.

-- 
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/2344#issuecomment-457812259

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Jan 2019 21:06:03 -0800

@marten-seemann 3 PTO is not going to defend the server here, because an attacker can control the value. It can delay the Initial packets that it sends (carrying ACKs) so that PTO becomes huge.

-- 
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/2344#issuecomment-458000211

---

From: Marten Seemann <[email-masked]>
Date: Sun, 27 Jan 2019 21:42:18 -0800

If I understand correctly, the server switches to 1-RTT right after receiving the Client Initial, doesn't it? That means that PTO will have its initial value, and not be client-controlled.
Obviously, this could be a problem on long RTT connections, so maybe that rule about dropping packets needs to be changed.

-- 
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/2344#issuecomment-458005018

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 27 Jan 2019 22:17:18 -0800

> If I understand correctly, the server switches to 1-RTT right after receiving the Client Initial, doesn't it? That means that PTO will have its initial value, and not be client-controlled.

In the scenario that we are discussing (yeah the thread is getting long), the attacker sends the Initial packet that contains an ACK to the server's Initial. That means that if an attacker can for example send the ACK after 3 seconds (3 seconds of RTO!) to have an open window of additional 9 seconds to perform an attack.

-- 
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/2344#issuecomment-458010575

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Jan 2019 17:09:58 -0800

I am concerned with the attack in which the 0-RTT data is replayed by a third party, maybe also with a replayed "retry token". Do we want more than 3 packets there? Do we really want to allow sending a large flow control window of data?

Also, 0-RTT may very well be rejected by the server. Sending something that changes connection state looks weird, because all these frames can be dropped.

-- 
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/2344#issuecomment-459174972

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2019 17:14:22 -0800

Tokyo conclusion: limit this to stuff we know that we need.  This leaves CONNECTION_CLOSE, NEW_CONNECTION_ID, PATH_CHALLENGE, PATH_RESPONSE, and PING out for the moment, but if we identify a need, we would do the analysis regarding safety and make a decision.  This means that extensions would need to make their own assessment about safety.

-- 
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/2344#issuecomment-459175894

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Jan 2019 17:26:42 -0800

I think we need a complementary analysis on expected server behavior. For example, if MAX DATA increase, does that mean sending that much data right now, or does that mean sending a small amount now, and wait until handshake complete to send more?

-- 
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/2344#issuecomment-459178332

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Jan 2019 17:42:18 -0800

The congestion controller and the limitations on how many bytes can be sent to an unvalidated address are separate from flow control.  What frames are permitted in 0-RTT has no bearing on those limits.

-- 
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/2344#issuecomment-459181722