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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Looks pretty good.  Thanks for adding the detail here.

> @@ -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

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

>  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
 as a connection error of type PROTOCOL_VIOLATION.
 
 
-## Rejecting 0-RTT
+## Accepting and rejecting 0-RTT

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

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

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

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

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

```suggestion
A server rejects 0-RTT by sending a ServerHello without an `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.
+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

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

>  
-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'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