Date: Thu, 01 Aug 2019 15:09:06 -0700
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKZDUZ7ELP2TAXL6IMV3KCKYFEVBNHHBYXLIMY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2947/review/269903722@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2947@github.com>
References: <quicwg/base-drafts/pull/2947@github.com>
Subject: Re: [quicwg/base-drafts] Describe interaction between QUIC and TLS
 regarding saved 0-RTT state (#2947)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5d436302d25f9_308e3fcdfbacd95c140822";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/fG1UZF_nAr2-1LuKKLNrXGwkssE>


----==_mimepart_5d436302d25f9_308e3fcdfbacd95c140822
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

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
----==_mimepart_5d436302d25f9_308e3fcdfbacd95c140822
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@nharper</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/2947#discussion_r309916542">draft-ietf-quic-tls.md</a>:</p>
<pre style='color:#555'>&gt; @@ -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 &quot;early_data&quot; 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
</pre>
<p>It's already an informative ref, defined at the beginning of the file.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/2947?email_source=notifications&amp;email_token=AFTOJKYKDHM2RJ5XLBLHEVTQCNNIFA5CNFSM4IIVRW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCALGO2Q#discussion_r309916542">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK5MZHBGRW2PYT4BWW3QCNNIFANCNFSM4IIVRW7Q">mute the thread</a>.<img src="https://github.com/notifications/beacon/AFTOJK4CH4Q5S37CRIK67SLQCNNIFA5CNFSM4IIVRW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCALGO2Q.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2947?email_source=notifications\u0026email_token=AFTOJKYKDHM2RJ5XLBLHEVTQCNNIFA5CNFSM4IIVRW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCALGO2Q#discussion_r309916542",
"url": "https://github.com/quicwg/base-drafts/pull/2947?email_source=notifications\u0026email_token=AFTOJKYKDHM2RJ5XLBLHEVTQCNNIFA5CNFSM4IIVRW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCALGO2Q#discussion_r309916542",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5d436302d25f9_308e3fcdfbacd95c140822--