Subject: [quicwg/base-drafts] 0-RTT can't use transport parameters or 1-RTT frames (#2461)

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2019 18:50:04 -0800

While in theory a client could send 0-RTT after receiving 1-RTT, this is
not a good idea.  This PR ties down transport parameters and flow
control and prevents a client from using anything it learns in the
handshake or 1-RTT from affecting (or expanding) what it can do with
0-RTT.  This prevents a client from using 0-RTT indefinitely and creates
stronger bounds on what 0-RTT can be used for.

Closes #2458, #2360.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2461

-- Commit Summary --

  * 0-RTT can't use transport parameters or 1-RTT frames
  * Add error condition

-- File Changes --

    M draft-ietf-quic-transport.md (46)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2461.patch
https://github.com/quicwg/base-drafts/pull/2461.diff

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Feb 2019 03:07:51 +0000 (UTC)

kazuho approved this pull request.

LGTM modulo the very minor concern below.

 A client SHOULD instead generate a fresh cryptographic handshake message and
 start packet numbers from 0.  This ensures that new 0-RTT packets will not use
 the same keys, avoiding any risk of key and nonce reuse; this also prevents
 0-RTT packets from previous handshake attempts from being accepted as part of
 the connection.
 
+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets can't contain any response to
+packets a server sends.  For instance, a client cannot send an ACK frame in a

Maybe it's worth clarifying that: "any response to _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/pull/2461#pullrequestreview-203012122

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2019 19:13:51 -0800

@martinthomson pushed 1 commit.

50b8e85285ba333798cdc083b62608766a37cbe3  More clarity

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/683c33ca20260aae56b22910bad7f112745076a3..50b8e85285ba333798cdc083b62608766a37cbe3

---

From: ianswett <[email-masked]>
Date: Wed, 13 Feb 2019 07:12:30 -0800

ianswett approved this pull request.

I think this is ok, but I think it's going to be difficult to get this correct in practice.  I expect most implementations will migrate to 1-RTT keys as soon as possible and try to avoid writing special logic for this case, but I can't come up with a way to force clients to do 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/pull/2461#pullrequestreview-203263950

---

From: MikkelFJ <[email-masked]>
Date: Wed, 13 Feb 2019 15:34:18 +0000 (UTC)

mikkelfj commented on this pull request.

```suggestion
from the server.  This means that 0-RTT packets cannot contain any response to
```

-- 
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/2461#pullrequestreview-203277589

---

From: MikkelFJ <[email-masked]>
Date: Wed, 13 Feb 2019 07:38:27 -0800

+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets can't contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.
+

A server MAY close a connection with the error PROTOCOL_VIOLATION if it is able to observe that a client sends 0-RTT packets based on any information received in 1-RTT packets, such as using increased flow control credits or stream identifiers.

-- 
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/2461#pullrequestreview-203280213

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Feb 2019 10:12:32 -0800

MikeBishop commented on this pull request.

The issue says that the Tokyo consensus was to recommend that servers check, but not require it.  This only says that servers MAY check.  Should there be a SHOULD/RECOMMENDED somewhere in 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/pull/2461#pullrequestreview-203366877

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Feb 2019 13:59:22 -0800

@ianswett 
> I think this is ok, but I think it's going to be difficult to get this correct in practice. I expect most implementations will migrate to 1-RTT keys as soon as possible and try to avoid writing spe…

I think it's possible. I think that's what the PR is trying to suggest is that a server can:
* enforce limits based on TP to streams-related frames sent using 0-RTT packets (see #2461)
* refuse to handle any of the following frames in a 0-RTT packet: ACK, PATH_RESPONSE, RETIRE_CONNECTION_ID (see #2458)

-- 
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/2461#issuecomment-463392078

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Feb 2019 22:23:22 +0000 (UTC)

> * enforce limits based on TP to streams-related frames sent using 0-RTT packets

Actually, enforce limits based on the TP *from last time* which are embedded in the session ticket.  But yes -- the "correct" way of doing this is saying that there is a parallel set of flow control limits which never increase from the initial value, but which only apply during 0-RTT.  If the client always switches to 1-RTT ASAP, this will be the same as regular flow control provided that the client doesn't consume any higher initial flow control values in the transport parameters until the handshake completes.

-- 
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/2461#issuecomment-463399914

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Feb 2019 16:19:27 -0800

-- 
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/2461#pullrequestreview-203516141

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Feb 2019 17:47:14 -0800

fff940e2a6fcd80adc9cd696052970f6ca0617aa  decontraction

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/50b8e85285ba333798cdc083b62608766a37cbe3..fff940e2a6fcd80adc9cd696052970f6ca0617aa

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Feb 2019 17:56:16 -0800

I tend to agree with @ianswett that policing limits here will be annoying, even if it is theoretically possible.  Thankfully, we get most of the benefits if only a small number of implementations police 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/pull/2461#issuecomment-463453758

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Feb 2019 17:56:51 -0800

1c9fcc313fa887226283627b0e9fa0916a9c8942  Add an allowance for server error

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/fff940e2a6fcd80adc9cd696052970f6ca0617aa..1c9fcc313fa887226283627b0e9fa0916a9c8942

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Feb 2019 12:49:08 -0800

I know we agreed to this is Tokyo, but seeing the actual PR made me realize how complex and hard to enforce this is. Would it be possible to solve the issue in a simpler way by saying something along the lines of the following? `Once a server receives a valid 1-RTT packet with packet number n, any 0-RTT packet it receives with packet number greater than n MUST be ignored.` That way clients can't keep sending 0-RTT forever since they'll have to send a 1-RTT ACK to unblock the server-to-client flow control at some point.

-- 
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/2461#issuecomment-463789830

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 21:04:42 +0000 (UTC)

> Once a server receives a valid 1-RTT packet with packet number n, any 0-RTT packet it receives with packet number greater than n MUST be ignored.

This is already the case.  It fails to solve any of the problems we are faced with though.

-- 
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/2461#issuecomment-463795748

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Feb 2019 13:11:53 -0800

@DavidSchinazi, if you want to change the decision at the interim, that's decidedly a question for the issue/list.

> This is already the case. It fails to solve any of the problems we are faced with though.

@martinthomson, can you point to that restriction?  I agree that it's intended, but I can't find it.

If we have that, you have to ignore 0-RTT packets sent after 1-RTT has started.  If you withhold putting any increases in flow control into effect until you've seen that 1-RTT packet, you're done fixing the problem we discussed.  That might be a simpler way to describe (or at least to implement) this prohibition.

-- 
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/2461#issuecomment-463798431

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 13:17:28 -0800

https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.9 says:

> https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.9

We already have issues on file for not reading 1-RTT and then sending more 0-RTT.  They even have PRs.

-- 
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/2461#issuecomment-463800526

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Feb 2019 13:29:04 -0800

Ah, I was looking in -transport.  That prohibits the client from going back to 0-RTT, and prohibits the server from accepting 0-RTT starting 3RTO after the server first sends a 1-RTT packet, but doesn't appear to require the server to check that the client didn't reverse itself by dropping packets.

(This *is* the issue/PR about not allowing the client to stay in 1-RTT, isn'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/pull/2461#issuecomment-463804848

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 21:29:43 +0000 (UTC)

Gah, too many windows.  Sorry.

-- 
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/2461#issuecomment-463805070

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 13:29:45 -0800

Closed #2461.

-- 
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/2461#event-2140925058

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Feb 2019 14:08:18 -0800

@MikeBishop I wouldn't say I'm explicitly trying to change anything decided in Tokyo, I'm trying to understand why I'm failing to understand what problem this PR solves.

> Once a server receives a valid 1-RTT packet with packet number n, any 0-RTT packet it receives with packet number greater than n MUST be ignored.

So I don't think we already do that. Could you elaborate on what problem is solved by this PR that wouldn't be solved by my check above?

-- 
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/2461#issuecomment-463820198

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Feb 2019 14:11:35 -0800

(To be clear, @martinthomson pasted the URL again as the quote, and I expanded it to some of the relevant text.)  I think what he was meaning to point to was this:
> Though an endpoint might retain older keys, new data MUST be sent at the highest
currently-available encryption level.  Only ACK frames and retransmissions of
data in CRYPTO frames are sent at a previous encryption level.  These packets
MAY also include PADDING frames.

So the client is prohibited from doing that, but the server isn't currently obligated to check.  I've tried to create something along the lines you suggest in #2466 -- can you take a look?

-- 
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/2461#issuecomment-463821378

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 14:23:45 -0800

Reopened #2461.

-- 
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/2461#event-2141043848

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 14:24:28 -0800

Too little sleep.  I still think that this is better than #2466.  Comments why over there.

-- 
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/2461#issuecomment-463826296

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Feb 2019 19:48:20 -0800

janaiyengar commented on this pull request.

A few suggestions, minor.

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated

This is difficult to read. How about:
"When sending frames in 0-RTT packets, a client MUST only use remembered transport parameters; importantly, it MUST NOT use updated values that it learns from the server's updated transport parameters or from frames received in 1-RTT packets."

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated
+transport parameters or frames carried in 1-RTT when sending frames in 0-RTT
+packets.  Updated values of transport parameters from the handshake only apply

```suggestion
packets.  Updated values of transport parameters from the handshake apply only
```

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated
+transport parameters or frames carried in 1-RTT when sending frames in 0-RTT
+packets.  Updated values of transport parameters from the handshake only apply
+to 1-RTT packets.  For instance, flow control limits from remembered transport
+parameters apply to all 0-RTT packets even if those values are increased by the
+handshake; increased limits from frames cannot be applied, because the client

```suggestion
handshake.  Increased flow control limits from frames cannot be applied, because the client
```

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated
+transport parameters or frames carried in 1-RTT when sending frames in 0-RTT
+packets.  Updated values of transport parameters from the handshake only apply
+to 1-RTT packets.  For instance, flow control limits from remembered transport
+parameters apply to all 0-RTT packets even if those values are increased by the
+handshake; increased limits from frames cannot be applied, because the client

I might even suggest dropping the second half, after "increased limits from frames".

+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets cannot contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.  A server

New paragraph -- this last sentence is not related to the earlier discussion in this para.
```suggestion
acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet. 

A server
```

-- 
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/2461#pullrequestreview-206646721