Subject: [quicwg/base-drafts] describe how 0-RTT is accepted and rejected (#2841)

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 16:33:27 -0700

Fixes #2829. Fixes #2840.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * describe how 0-RTT is accepted and rejected

-- File Changes --

    M draft-ietf-quic-tls.md (13)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2841.patch
https://github.com/quicwg/base-drafts/pull/2841.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/2841

---

From: MikkelFJ <[email-masked]>
Date: Mon, 24 Jun 2019 16:44:24 -0700

mikkelfj commented on this pull request.

-A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This also prevents
-QUIC from sending 0-RTT data. A server will always reject 0-RTT if it sends a
-TLS HelloRetryRequest.
+A server accepts 0-RTT by sending the EarlyDataIndication in the ServerHello
+(see Section 4.10.2 of {{!TLS13}}). A server that accepts 0-RTT MUST process and
+acknowledge all 0-RTT packets that it receives.

```suggestion
acknowledge all valid 0-RTT packets that it receives.
```

-- 
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/2841#pullrequestreview-253710777

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 16:59:22 -0700

marten-seemann commented on this pull request.

How would you even acknowledge an invalid packet?

-- 
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/2841#discussion_r296960353

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 17:02:00 -0700

DavidSchinazi commented on this pull request.

+
+A server rejects 0-RTT by sending a ServerHello with the EarlyDataIndication.

I think you meant *without* EarlyDataIndication

-- 
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/2841#pullrequestreview-253714756

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 17:02:48 -0700

-A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This also prevents
-QUIC from sending 0-RTT data. A server will always reject 0-RTT if it sends a
-TLS HelloRetryRequest.
+A server accepts 0-RTT by sending the EarlyDataIndication in the ServerHello
+(see Section 4.10.2 of {{!TLS13}}). A server that accepts 0-RTT MUST process and
+acknowledge all 0-RTT packets that it receives.
+
+A server rejects 0-RTT by sending a ServerHello with the EarlyDataIndication.
+When rejecting 0-RTT, a server MUST NOT process any 0-RTT packets, even if it is
+in possesion of the keys to do so. A server will always reject 0-RTT if it sends
+a TLS HelloRetryRequest.

I think we should add text specifying what a client does if the server rejects 0-RTT but ACKs 0-RTT packets - probably PROTOCOL_VIOLATION.

-- 
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/2841#pullrequestreview-253714920

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 17:03:37 -0700

@marten-seemann pushed 1 commit.

de85a4b75d306acb66899838e2a2eca22e92200e  s/with/without for rejecting 0-RTT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/1585f08a705d1fca1b600e503d4f94355fceef5b..de85a4b75d306acb66899838e2a2eca22e92200e

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 17:08:54 -0700

94cbd5aeea96f06b869c735cc13be51ddcd06d33  error when 0-RTT is acked when 0-RTT is rejected

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/de85a4b75d306acb66899838e2a2eca22e92200e..94cbd5aeea96f06b869c735cc13be51ddcd06d33

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 17:09:53 -0700

Thanks. I added a sentence about 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/2841#discussion_r296962176

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 17:15:16 -0700

DavidSchinazi approved this pull request.

-- 
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/2841#pullrequestreview-253717642

---

From: MikkelFJ <[email-masked]>
Date: Mon, 24 Jun 2019 17:50:20 -0700

Fair point, but that only makes it harder to comply.

-- 
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/2841#discussion_r296968700

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 24 Jun 2019 17:57:14 -0700

kazuho approved this pull request.

I think you might want to clarify that the client uses the early_data extension when it is going to send 0-RTT packets. That's implied by this sentence (because in TLS a server cannot send the early_data extension unless client has sent one), though.

I am not sure if we need to have this sentence, especially using a normative MUST. IMO, a server should be allowed to drop 0-RTT packets if it needs to (like resource starvation).

Maybe changing the sentence to "Then, the server processes and acknowledges the 0-RTT packets that it receives." would be fine.

-- 
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/2841#pullrequestreview-253725010

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 19:15:30 -0700

Makes sense. I applied your suggestion.

-- 
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/2841#discussion_r296981961

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 19:15:31 -0700

6facb9d770b99508871422b28c59911f06c66301  remove normative language for receiving 0-RTT packets

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/94cbd5aeea96f06b869c735cc13be51ddcd06d33..6facb9d770b99508871422b28c59911f06c66301

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 19:21:31 -0700

cedada14714c6bb7e8ff1e3b30134df3a71f8f6c  add a paragraph describing how a client enables 0-RTT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/6facb9d770b99508871422b28c59911f06c66301..cedada14714c6bb7e8ff1e3b30134df3a71f8f6c

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 19:21:47 -0700

@kazuho I added a paragraph about that. PHAL.

-- 
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/2841#discussion_r296983017

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 24 Jun 2019 21:19:49 -0700

kazuho commented on this pull request.

> @@ -613,16 +613,27 @@ by the "initial_max_data" transport parameter supplied by the server.  A client
 MUST treat receipt of a NewSessionTicket that contains an "early_data" extension
 with any other value as a connection error of type PROTOCOL_VIOLATION.
 
+A client that wishes to send early data uses the "early_data" extension in the

Maybe s/early data/0-RTT packets/? I do not think QUIC sends early data.

> @@ -613,16 +613,27 @@ by the "initial_max_data" transport parameter supplied by the server.  A client
 MUST treat receipt of a NewSessionTicket that contains an "early_data" extension
 with any other value as a connection error of type PROTOCOL_VIOLATION.
 
+A client that wishes to send early data uses the "early_data" extension in the
+ClientHello message of a subsequent handshake (see Section 4.10.2 of
+{{!TLS13}}). It then sends the application data in 0-RTT packets.
+
 Early data within the TLS connection MUST NOT be used.  As it is for other TLS
 application data, a server MUST treat receiving early data on the TLS connection

Maybe irrelevant to this PR, but s/TLS connection/CRYPTO stream/.

I think we need to state "the early_data extension" instead of "EarlyDataIndication".

EarlyDataIndication is type of a structure, that affects the peer only if it is being carried by the early_data extension.

-A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This also prevents
-QUIC from sending 0-RTT data. A server will always reject 0-RTT if it sends a
-TLS HelloRetryRequest.
+A server rejects 0-RTT by sending a ServerHello without the EarlyDataIndication.

Same as above.

-A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This also prevents
-QUIC from sending 0-RTT data. A server will always reject 0-RTT if it sends a
-TLS HelloRetryRequest.
+A server rejects 0-RTT by sending a ServerHello without the EarlyDataIndication.
+A server will always reject 0-RTT if it sends a TLS HelloRetryRequest.  When
+rejecting 0-RTT, a server MUST NOT process any 0-RTT packets, even if it is in
+possesion of the keys to do so.  When 0-RTT was rejected, a client MUST treat
+receipt of an acknowledgement for a 0-RTT packet as a connection error of type

I wonder if this needs to be a MUST (in sense that the client is required to track the packet numbers it has used for 0-RTT packets, even when it knows that the server has rejected 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/pull/2841#pullrequestreview-253762280

---

From: monkey-mas <[email-masked]>
Date: Mon, 24 Jun 2019 21:30:59 -0700

monkey-mas commented on this pull request.

 application data, a server MUST treat receiving early data on the TLS connection
 as a connection error of type PROTOCOL_VIOLATION.

-## Rejecting 0-RTT
+## Accepting and rejecting 0-RTT

super-nit: Every first letter in title can be capitalized? :) Maybe `Accepting And Rejecting 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/pull/2841#pullrequestreview-253765787

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 00:24:40 -0700

a6c47ee88ac7ca211a21779b24ab3cec6e5120f9  capitalize all words in section title

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/c0b38a3c32745a5ee2fe643c21d1e34b51ab66eb..a6c47ee88ac7ca211a21779b24ab3cec6e5120f9

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 00:28:09 -0700

9440ab9a25a7c5254b526cdca15c38f98bf0abfc  s/EarlyDataIndication/early_data extension/g

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/a6c47ee88ac7ca211a21779b24ab3cec6e5120f9..9440ab9a25a7c5254b526cdca15c38f98bf0abfc

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 00:29:44 -0700

I don't think you need to explicitly track the packet numbers. Here's how I would implement this:
When 0-RTT is rejected, I clear all recovery state for the 0-RTT packets that I sent earlier. Now when receiving an ACK, I just need to run the standard check that it only acknowledges packets that I actually sent. No special case is required to handle this MUST.

-- 
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/2841#discussion_r297043018

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 00:30:42 -0700

I'm not sure what would be the best way to phrase it. We have 3 different CRYPTO streams though, one for every encryption level.

-- 
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/2841#discussion_r297043344

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 03:50:22 -0700

Good point. Rereading the sentence, I think we can remove it as a whole.

As of -12, we transmit TLS handshake messages instead of TLS records. That means that there is no way of transmitting 0-RTT "records" using the CRYPTO 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/pull/2841#discussion_r297125833

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 03:57:58 -0700

To clarify, what is being discussed here is about how to process ACKs containing invalid packet numbers. The general rule we have is that _an endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition_ ([section 13.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.13.1.1)).

Is there a reason we need something different for 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/pull/2841#discussion_r297128544

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 07:26:08 -0700

5fa9df2483be425134fd36c520303f80d6cb8f56  clients SHOULD detect ACKs for 0-RTT packets after 0-RTT rejection

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/9440ab9a25a7c5254b526cdca15c38f98bf0abfc..5fa9df2483be425134fd36c520303f80d6cb8f56

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 07:26:13 -0700

Makes sense. I updated the text.

-- 
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/2841#discussion_r297216565

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 07:27:34 -0700

Can we do that in a separate PR? I think it's orthogonal, and this PR already has a lot of commits.

-- 
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/2841#discussion_r297217320

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 07:28:29 -0700

Done.

-- 
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/2841#discussion_r297217928

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 07:28:31 -0700

6ec7024f9d6929f4a7b586d9732c7c87a06fa835  a client sends 0-RTT packets, not early data

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/5fa9df2483be425134fd36c520303f80d6cb8f56..6ec7024f9d6929f4a7b586d9732c7c87a06fa835

---

From: ianswett <[email-masked]>
Date: Tue, 25 Jun 2019 13:02:06 -0700

ianswett approved this pull request.

-- 
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/2841#pullrequestreview-254237682

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 14:25:57 -0700

Can we have "if it is able to detect the condition"?

I do not think we need to recommend all clients implement the check only for this particular purpose.

-- 
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/2841#discussion_r297400698

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 15:38:17 -0700

martinthomson commented on this pull request.

Looks pretty good.  Thanks for adding the detail here.

```suggestion
A client that wishes to send 0-RTT packets uses the "early_data" extension in the
```

-## Rejecting 0-RTT

Yes, we use title case, as per the RFC style guide.

```suggestion
## Accepting and Rejecting 0-RTT
```

```suggestion
A server accepts 0-RTT by sending an `early_data` extension in the ServerHello
```

```suggestion
A server rejects 0-RTT by sending a ServerHello without an `early_data` extension.
```

"even if it could" might be enough.  A server shouldn't even generate those keys, and this phrasing creates an impression that one might.

I'm OK with this MUST.  There are ways to manage this that work reasonably well.

-- 
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/2841#pullrequestreview-254304490

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 16:21:09 -0700

@martinthomson I disagree that is is easy to detect.

It is true that it is easy for a QUIC stack that uses different packet number spaces to detect this error. This is because all you need to do is remember the largest PN used for the 0-RTT packet, and compare that with ACKs you receive in the application space.

OTOH, this is difficult for a QUIC stack that uses unified packet number space. Such stacks would be required to remember all the PNs being used for sending 0-RTT packets.

The other question is if we need to require endpoints to posses the 0-RTT keys, even after it detects that 0-RTT has been rejected. Unless we require that, having this MUST becomes much useless.

Speaking of text, I think there are four options:
a) MUST detect and close
b) SHOULD detect and close
c) MUST close if detected
d) SHOULD close if detected

As stated, I oppose to _a_ because it could be hard to detect. I think _c_ is fine. I might agree that _b_, _d_ might not be good, though I wonder what's the necessity to have something different from the general rule of handling ACKs carrying invalid PNs. Maybe the general rule needs to be changed to MUST.

-- 
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/2841#discussion_r297431485

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 16:22:38 -0700

kazuho requested changes on this pull request.

Changing my position to "request changes" due to the reasons stated in https://github.com/quicwg/base-drafts/pull/2841#discussion_r297431485.

-- 
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/2841#pullrequestreview-254317874

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 17:38:38 -0700

Makes sense. Filed PR #2845.

-- 
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/2841#discussion_r297445937

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 18:04:46 -0700

@kazuho There's no such thing as a unified PN space. QUIC has 3 packet number spaces, and there's no way to opt out of that. If a QUIC implementation decides to do weird things with the packet numbers (i.e. if it doesn't start every PN space from 0, as the spec suggests), it shouldn't be surprised to run into additional complexity...

That being said, as you point out in https://github.com/quicwg/base-drafts/pull/2841#discussion_r297128544, we're using a SHOULD elsewhere, so for consistency I changed it to a SHOULD here as well. I don't think that we need a "if it is able to detect the condition" sub-clause here, as the SHOULD already allows you to skip the check, if your implementation is not able to perform 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/2841#discussion_r297449947

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 18:06:16 -0700

c9386c4c207c09c4cf89e3141b2b5e4db72d65b5  *an* early_data extension

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/6ec7024f9d6929f4a7b586d9732c7c87a06fa835..c9386c4c207c09c4cf89e3141b2b5e4db72d65b5

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 18:09:11 -0700

32a7bb0fbb5e0928d1c8433a05191b1f9b407f7a  rejecting 0-RTT means not generating 0-RTT keys

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/c9386c4c207c09c4cf89e3141b2b5e4db72d65b5..32a7bb0fbb5e0928d1c8433a05191b1f9b407f7a

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 18:09:31 -0700

Makes sense. Updated the PR.

-- 
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/2841#discussion_r297450644

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 18:21:39 -0700

@marten-seemann The spec having different packet number spaces does not necessarily mean that every QUIC stack should be having different PN counters for each number space for the packets it sends. It is entirely plausible for a QUIC stack to use just one packet number space for the packets it sends.

That said, ...

> as you point out in https://github.com/quicwg/base-drafts/pull/2841#discussion_r297128544, we're using a SHOULD elsewhere, so for consistency I changed it to a SHOULD here as well.

Thank you for the change. I appreciate it.

> I don't think that we need a "if it is able to detect the condition" sub-clause here, as the SHOULD already allows you to skip the check, if your implementation is not able to perform it.

IIRC, the sub-clause "if it is able to detect the condition" was added intentionally to the general rule, because people were concerned about the text being interpreted as to recommend having a way to detect such errors. I think the text proposed in this PR has the same problem, and my preference is to address it in the same manner.

I think that one path forward might be to, instead of clarifying the action here, incorporate the handling of acknowledgements of 0-RTT packets into the provision of 13.1.1.

I mean, changing
> An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition.

to something like:
> An endpoint SHOULD treat receipt of an acknowledgment for a packet that the server would not have processed as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition. This includes receiving an ACK frame containing a packet number that the endpoint has not sent, as well as acknowledgements for 0-RTT packets when the server has rejected the use of 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/pull/2841#discussion_r297452432

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 18:40:50 -0700

@kazuho
> The spec having different packet number spaces does not necessarily mean that every QUIC stack should be having different PN counters for each number space for the packets it sends. It is entirely plausible for a QUIC stack to use just one packet number space for the packets it sends.

The spec is actually quite clear about this (https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.12.3)
>  Packet numbers in each space start at packet number 0.

Now I agree that it's possible to ignore this sentence and start the packet number wherever you want (if you're willing to tolerate the loss recovery response this provokes, i.e. an early ACK because of detected reordering). However, I don't think we need to modify the spec because of self-inflicted complexities of non-compliant implementations.

> IIRC, the sub-clause "if it is able to detect the condition" was added intentionally to the general rule, because people were concerned about the text being interpreted as to recommend having a way to detect such errors.

I think we added this text because for 1-RTT packets, you clear out old ACK ranges from time to time. When receiving an ACK for a very old packet you'd then not be able to check if you actually sent this packet, because you already removed the tracking 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/pull/2841#discussion_r297455344

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 19:00:09 -0700

@marten-seemann Contrary to what you state, the spec is clear about skipping PN 0 (or any packet number in a packet number space) is a permitted behavior. Quoting from [section 21.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.21.3), _an endpoint MAY skip packet numbers when sending packets to detect this behavior._

Using unified packet number space on the send side is precisely an act of "skipping packet numbers when sending packets," skipping those that have been used in another packet number space.

> I think we added this text because for 1-RTT packets, you clear out old ACK ranges from time to time. When receiving an ACK for a very old packet you'd then not be able to check if you actually sen…

I'm not sure if I agree with the assumption, but granted that it is true, I think it would be an argument _for_ having the same sub-clause for 0-RTT packets as well. ACK ranges are cleared out from time to time. Then, why do we need to handle ranges for 0-RTT packets specially, only when the server rejects 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/pull/2841#discussion_r297458292

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 19:10:34 -0700

@kazuho Of course you **can** skip packet numbers, since this is indistinguishable from packet loss.
The text you're quoting is about the optimistic ACK attack, and describes a mechanism how you skip a single packet number from time to time **in order to detect this attack**. It is not intended to start a packet number space at a much higher packet number. Furthermore, if I understand your point here correctly, what you actually want to do is **not** to perform the check if a skipped packet number is acknowledged, so you really can't use this text as a justification...

-- 
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/2841#discussion_r297459796

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 19:21:35 -0700

Using unified packet number space on the send side is an easy way of detecting an optimistic ACK attack. Because all you need is a single ACK map (instead of ACK map per every packen number space), that allows each of the entry to have the epochs associated. Optimistic ACK is detected when you receive an ACK in an unexpected epoch.

> Furthermore, if I understand your point here correctly, what you actually want to do is not to perform the check if a skipped packet number is acknowledged, so you really can't use this text as a justification...

I think you are missing the fact that there are two topics being discussed in parallel. One is if use of unified packet number space is OK. That relates to if the detection could be MUST. For that, we are in agreement that it can be SHOULD. Therefore, I think it's getting off-topic.

The other discussion is if we need the "if detected" sub-clause. I do not think I am using the existence of QUIC stacks using unified packet number space on the send side as a justification to argue for having the sub-clause.

-- 
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/2841#discussion_r297461418

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 19:36:52 -0700

I think the suggestion you made in https://github.com/quicwg/base-drafts/pull/2841#discussion_r297452432 is a good one. I updated the PR.

-- 
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/2841#discussion_r297463683

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 19:40:13 -0700

2ddaf6d39e2c08a4ec6128a87815bdfac2140d66  apply @kazuho's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/32a7bb0fbb5e0928d1c8433a05191b1f9b407f7a..2ddaf6d39e2c08a4ec6128a87815bdfac2140d66

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 19:42:07 -0700

0400ce1b3704fdfe5fbacf10179b0357afd02bbe  early_data is sent in the EE, not the SH

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/2ddaf6d39e2c08a4ec6128a87815bdfac2140d66..0400ce1b3704fdfe5fbacf10179b0357afd02bbe

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 20:09:31 -0700

Thank you for the changes. Looks good to me modulo the points below.

-## Rejecting 0-RTT
+## Accepting and Rejecting 0-RTT
+
+A server accepts 0-RTT by sending an early_data extension in the ServerHello

s/ServerHello/EncryptedExtensions/

-## Rejecting 0-RTT
+## Accepting and Rejecting 0-RTT
+
+A server accepts 0-RTT by sending an early_data extension in the ServerHello
+(see Section 4.10.2 of {{!TLS13}}).  The server then processes and acknowledges

s/4.10.2/4.2.10/

> @@ -2918,7 +2918,9 @@ received packets in preference to packets received in the past.
 
 An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not
 send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect

s/for a packet it did not send/for a packet that the server would not have processed/

The change is necessary because 0-RTT packets are sent (but not expected to be processed).

-- 
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/2841#pullrequestreview-254361946

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 20:22:44 -0700

607a9f44394882544e9ac2a600eb11bdf90e4335  another fix for early_data being sent in EE, not SH

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/0400ce1b3704fdfe5fbacf10179b0357afd02bbe..607a9f44394882544e9ac2a600eb11bdf90e4335

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 20:23:09 -0700

9c7fa1ab06c999a22c31194c0d2b10d38fd06de1  fix reference to RFC 8446

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841/files/607a9f44394882544e9ac2a600eb11bdf90e4335..9c7fa1ab06c999a22c31194c0d2b10d38fd06de1

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 20:24:00 -0700

-## Rejecting 0-RTT

Thanks!

-- 
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/2841#discussion_r297470780

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 20:24:11 -0700

-## Rejecting 0-RTT

Fixed.

-- 
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/2841#discussion_r297470799

---

From: Marten Seemann <[email-masked]>
Date: Tue, 25 Jun 2019 20:24:43 -0700

This applies in both directions though. Maybe we shouldn't update the transport doc at all?

-- 
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/2841#discussion_r297470929

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Jun 2019 20:26:23 -0700

My bad, I think the replacement should be "for a packet that the peer would not have processed".

-- 
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/2841#discussion_r297471220

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 20:43:11 -0700

martinthomson approved this pull request.

-- 
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/2841#pullrequestreview-254368716