Date: Wed, 13 Dec 2017 20:41:24 +0000 (UTC)
From: Patrick McManus <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abb20db7a9ece85268c10cdbdef87260c53dee7a1892cf000000011649527492a169ce10cd45d2@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1015@github.com>
Subject: [quicwg/base-drafts] Removing Transport Parameters from
 new_session_ticket (#1015)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5a31907477033_46e93ff92f606f2c258680";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ci-5zwrN2cFws8cTS9piiX90fLU>

----==_mimepart_5a31907477033_46e93ff92f606f2c258680
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

transport 7.4.2 says that if a new_session_ticket contains the transport parameters extension those parameters should be used as overrides when making future 0-rtt connections with the ticket. 

This is a little hairy to implement and seems to add a bunch of un-necessary complexity and confusion about which transport parameters to expect. The latter is especially concerning because a mixup there results in hard errors.

The motivation, afaict, is to allow smaller defaults for things that are flow controlled on 0rtt vs 1rtt. Presumably the 0-rtt connection would issue a bunch of flow control credits shortly after 1rtt keys are established to bring those two connection styles up to parity with each other.

I propose that transport parameters are removed from NST and the server simply always behaves in this way (i.e. use conservative values in transport parameters and then issue flow control credits when 1RT keys are established. irrespective of whether or not a 0-rtt phase was ever used).

Given that a server that is not going to authenticate its client can send flow control credits at 0.5RTT these updates arrive in the same flight as the handshake in the 1rtt case - i.e. its effectively not adding any latency.. certainly not enough latency to exhaust those smaller defaults.

The TLS APIs here can create quite a bit of complexity... e.g. great care needs to be taken to correctly correlate transport parameters with the right context.. it is a solvable problem, but the complexity seems un-necessary.


-- 
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/1015
----==_mimepart_5a31907477033_46e93ff92f606f2c258680
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p>transport 7.4.2 says that if a new_session_ticket contains the transport parameters extension those parameters should be used as overrides when making future 0-rtt connections with the ticket.</p>
<p>This is a little hairy to implement and seems to add a bunch of un-necessary complexity and confusion about which transport parameters to expect. The latter is especially concerning because a mixup there results in hard errors.</p>
<p>The motivation, afaict, is to allow smaller defaults for things that are flow controlled on 0rtt vs 1rtt. Presumably the 0-rtt connection would issue a bunch of flow control credits shortly after 1rtt keys are established to bring those two connection styles up to parity with each other.</p>
<p>I propose that transport parameters are removed from NST and the server simply always behaves in this way (i.e. use conservative values in transport parameters and then issue flow control credits when 1RT keys are established. irrespective of whether or not a 0-rtt phase was ever used).</p>
<p>Given that a server that is not going to authenticate its client can send flow control credits at 0.5RTT these updates arrive in the same flight as the handshake in the 1rtt case - i.e. its effectively not adding any latency.. certainly not enough latency to exhaust those smaller defaults.</p>
<p>The TLS APIs here can create quite a bit of complexity... e.g. great care needs to be taken to correctly correlate transport parameters with the right context.. it is a solvable problem, but the complexity seems un-necessary.</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/issues/1015">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkqzIHuc0RECPLyg3mk6_7lieeTP9qks5tADZ0gaJpZM4RBJVF">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AWbkq5mCZsOuqKx2QoJN-DDOqMdzew4Jks5tADZ0gaJpZM4RBJVF.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/quicwg/base-drafts/issues/1015"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<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://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Removing Transport Parameters from new_session_ticket (#1015)"}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/issues/1015"}}}</script>
----==_mimepart_5a31907477033_46e93ff92f606f2c258680--