Re: [quicwg/base-drafts] Describe interaction between QUIC and TLS regarding saved 0-RTT state (#2947)

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.



> @@ -279,13 +279,14 @@ components:
 protection being called out specially.
 
 ~~~
-+------------+                        +------------+
-|            |<- Handshake Messages ->|            |
-|            |<---- 0-RTT Keys -------|            |
-|            |<--- Handshake Keys-----|            |
-|   QUIC     |<---- 1-RTT Keys -------|    TLS     |
-|            |<--- Handshake Done ----|            |
-+------------+                        +------------+
++------------+                               +------------+
+|            |<---- Handshake Messages ----->|            |
+|            |<- Validate 0-RTT parameters ->|            |
+|            |<--------- 0-RTT Keys ---------|            |
+|            |<------- Handshake Keys -------|            |
+|   QUIC     |<--------- 1-RTT Keys ---------|    TLS     |

We probably need to move the QUIC and TLS labels up by a line.

> @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
 Negotiation packet.  These packets do not signify rejection of 0-RTT.
 
 
+## Validating saved 0-RTT state

```suggestion
## Validating 0-RTT Configuration
```

> @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
 Negotiation packet.  These packets do not signify rejection of 0-RTT.
 
 
+## Validating saved 0-RTT state
+
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or reject early data from the client. Some of this
+decision is made by the TLS stack (e.g. checking that the cipher suite being

```suggestion
decision is made by the TLS stack (e.g., checking that the cipher suite being
```

> @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
 Negotiation packet.  These packets do not signify rejection of 0-RTT.
 
 
+## Validating saved 0-RTT state
+
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or reject early data from the client. Some of this
+decision is made by the TLS stack (e.g. checking that the cipher suite being
+resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and

QUIC doesn't save anything.  This is an implementation choice.  The key point is that QUIC requires that servers associate session configuration information with a resumed session.  The right thing to say here is that QUIC requires that a server be able to recover transport parameters for a resumed session, and different application protocols that use QUIC might have similar requirements regarding their configuration.  If transport parameters or application protocol configuration associated with a resumed session is not compatible with the current configuration of the server, the server MUST reject 0-RTT.

> @@ -629,6 +632,24 @@ A client MAY attempt to send 0-RTT again if it receives a Retry or Version
 Negotiation packet.  These packets do not signify rejection of 0-RTT.
 
 
+## Validating saved 0-RTT state
+
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or reject early data from the client. Some of this
+decision is made by the TLS stack (e.g. checking that the cipher suite being
+resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and
+imposes additional restrictions on when a server may accept early data. The TLS
+stack needs to check with the QUIC stack whether this saved state is valid for
+accepting early data.
+
+One example of such state that the QUIC stack checks when deciding whether or
+not to accept early data is the transport parameters extension. When HTTP/3

Transport parameters are the exhaustive set of things that the transport cares about.  But this implies otherwise.  I would concentrate on mentioning the h3 settings as an example of the sort of things that might be included.

Yes, we could define an extension to QUIC (the transport) that allowed state to be associated with a resumed sessions in a way that would affect this, but we don't need to do that now and our future selves can worry about how to integrate that with 0-RTT.

> +## Validating saved 0-RTT state
+
+When a server receives a ClientHello with the "early_data" extension, it has to
+decide whether to accept or reject early data from the client. Some of this
+decision is made by the TLS stack (e.g. checking that the cipher suite being
+resumed was included in the ClientHello; see Section 4.2.10 of {{!TLS13}}). QUIC
+saves additional transport and application state in a 0-RTT session ticket, and
+imposes additional restrictions on when a server may accept early data. The TLS
+stack needs to check with the QUIC stack whether this saved state is valid for
+accepting early data.
+
+One example of such state that the QUIC stack checks when deciding whether or
+not to accept early data is the transport parameters extension. When HTTP/3
+({{QUIC-HTTP}}) is used at the application layer, the SETTINGS frame from the
+previous session is another such example. This list is not intended to be
+exhaustive; future applications using QUIC may impose different restrictions.

```suggestion
For example, HTTP/3 ({{QUIC-HTTP}}) settings determine how 0-RTT from the client
is interpreted. Other applications using QUIC could have different requirements
for determining whether to accept or reject 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/2947#pullrequestreview-276309916