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

[Nick Harper <[e-mail]>]

nharper commented on this pull request.



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

It's already an informative ref, defined at the beginning of the file.

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