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

[Kazuho Oku <[e-mail]>]

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

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