Date: Wed, 13 Feb 2019 07:38:27 -0800
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab82c0550ed8ede64e1395c4a46dcbff71a7a4cd9b92cf00000001187bfbf392a169ce1869fe88@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2461/review/203280213@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2461@github.com>
References: <quicwg/base-drafts/pull/2461@github.com>
Subject: Re: [quicwg/base-drafts]  0-RTT can't use transport parameters or
 1-RTT frames  (#2461)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c6439f31bd52_742a3fc193ad45b4630e6";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/diPLf1IjwOG6Ndrz9sbyo88VtqI>


----==_mimepart_5c6439f31bd52_742a3fc193ad45b4630e6
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

mikkelfj commented on this pull request.



>  
 A client SHOULD instead generate a fresh cryptographic handshake message and
 start packet numbers from 0.  This ensures that new 0-RTT packets will not use
 the same keys, avoiding any risk of key and nonce reuse; this also prevents
 0-RTT packets from previous handshake attempts from being accepted as part of
 the connection.
 
+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets can't contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.
+
 

A server MAY close a connection with the error PROTOCOL_VIOLATION if it is able to observe that a client sends 0-RTT packets based on any information received in 1-RTT packets, such as using increased flow control credits or stream identifiers.

-- 
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/2461#pullrequestreview-203280213
----==_mimepart_5c6439f31bd52_742a3fc193ad45b4630e6
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@mikkelfj</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/2461#discussion_r256451414">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt;  
 A client SHOULD instead generate a fresh cryptographic handshake message and
 start packet numbers from 0.  This ensures that new 0-RTT packets will not use
 the same keys, avoiding any risk of key and nonce reuse; this also prevents
 0-RTT packets from previous handshake attempts from being accepted as part of
 the connection.
 
+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets can&#39;t contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.
+
 
</pre>
<p>A server MAY close a connection with the error PROTOCOL_VIOLATION if it is able to observe that a client sends 0-RTT packets based on any information received in 1-RTT packets, such as using increased flow control credits or stream identifiers.</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/2461#pullrequestreview-203280213">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkqxlqIIy1WYQmWPBZBKjvopieBcvRks5vNDFzgaJpZM4a4fJ9">mute the thread</a>.<img src="https://github.com/notifications/beacon/AWbkqwkOG6sECwpvbig6X1l7p8NrwEWGks5vNDFzgaJpZM4a4fJ9.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@mikkelfj commented on #2461"}],"action":{"name":"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/2461#pullrequestreview-203280213"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2461#pullrequestreview-203280213",
"url": "https://github.com/quicwg/base-drafts/pull/2461#pullrequestreview-203280213",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5c6439f31bd52_742a3fc193ad45b4630e6--