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

[Kazuho Oku <[e-mail]>]

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

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

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