Subject: [quicwg/base-drafts] text about rejecting 0-RTT is unclear (#2829)

From: Marten Seemann <[email-masked]>
Date: Sat, 22 Jun 2019 05:58:03 -0700

The spec says
> 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.

RFC 8446 says about rejecting 0-RTT:
>    -  Ignore the extension and return a regular 1-RTT response.  The server then skips past early data by attempting to deprotect received records using the handshake traffic key, discarding records which fail deprotection (up to the configured max_early_data_size).  Once a record is deprotected successfully, it is treated as the start of the client's second flight and the server proceeds as with an ordinary 1-RTT handshake.
>
>  -  Request that the client send another ClientHello by responding with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello.  The server then ignores early data by skipping all records with an external content type of "application_data" (indicating that they are encrypted), up to the configured max_early_data_size.

This doesn't really apply to QUIC, since we don't need a connection that requires us to read the bytes in order. The QUIC equivalent would be to drop all packets of packet type 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/issues/2829

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 23 Jun 2019 21:11:17 -0700

> The QUIC equivalent would be to drop all packets of packet type 0-RTT.

It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0-RTT (or not).

Merely dropping the packets is not sufficient. This is because the parameters of a connection depends on if 0-RTT has been received; for example, in case of HTTP/3, until the client receives a SETTINGS frame, the settings of previous connection is applied when 0-RTT is accepted, whereas the default settings defined by the specification is applied when 0-RTT is rejected.

-- 
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/issues/2829#issuecomment-504850056

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 23 Jun 2019 21:13:53 -0700

PS. What I think we need to clarify is that "use and acceptance" of 0-RTT is communicated the same way as TLS 1.3, by using the early_data extension.

That includes early_data extension sent in ClientHello, EncryptedExtensions, NewSessionTicket.

-- 
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/issues/2829#issuecomment-504850416

---

From: Marten Seemann <[email-masked]>
Date: Sun, 23 Jun 2019 21:21:56 -0700

Thanks @kazuho. That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.

-- 
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/issues/2829#issuecomment-504851736