Date: Mon, 21 Oct 2019 19:41:52 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKY443ROEW5B2OTBBN53XOWQBEVBNHHB4UHVOQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3111/544784567@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3111@github.com>
References: <quicwg/base-drafts/issues/3111@github.com>
Subject: Re: [quicwg/base-drafts] [Version Ossification] Alternative version
 and Initial Salt should be part of NEW_TOKEN (#3111)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5dae6c70812f4_2bd73fb1202cd95c1022cc";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/fBoJFgQ-VdQNvPMj2TkKPz_xJ2c>


----==_mimepart_5dae6c70812f4_2bd73fb1202cd95c1022cc
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

> @ianswett
> 
> > Aren't clients required to store transport parameters when doing resumption already, so this is moving it from one place they store to another?
> 
> That's a good point. I admit that the only one benefit of bundling the alternative version-salt is that the server can store and recover that from the token. That said, please let me reiterate that that is a huge benefit, as it provides the servers the capability of protecting the Initial packets from on-path intermediary in a cryptographically secure way.
> 
To clarify what you're getting from this that isn't achieved in TPs is that here you're guaranteed that when the client comes back with the version and salt, they'll also specify the Token.  But if these were in transport params, then the client might decide not to send the subsequently transmitted token with the version and salt or the corresponding token might not get delivered in time?

-- 
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/3111#issuecomment-544784567
----==_mimepart_5dae6c70812f4_2bd73fb1202cd95c1022cc
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<blockquote>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=20072817" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ianswett">@ianswett</a></p>
<blockquote>
<p>Aren't clients required to store transport parameters when doing resumption already, so this is moving it from one place they store to another?</p>
</blockquote>
<p>That's a good point. I admit that the only one benefit of bundling the alternative version-salt is that the server can store and recover that from the token. That said, please let me reiterate that that is a huge benefit, as it provides the servers the capability of protecting the Initial packets from on-path intermediary in a cryptographically secure way.</p>
</blockquote>
<p>To clarify what you're getting from this that isn't achieved in TPs is that here you're guaranteed that when the client comes back with the version and salt, they'll also specify the Token.  But if these were in transport params, then the client might decide not to send the subsequently transmitted token with the version and salt or the corresponding token might not get delivered in time?</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/3111?email_source=notifications&amp;email_token=AFTOJKZUKMFQA5D4RF2K4J3QPZR7BA5CNFSM4JB434ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4MBNY#issuecomment-544784567">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK7CROOMY6FGBXN5V7DQPZR7BANCNFSM4JB434ZA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJK3S7FOUOOTPNJP6BELQPZR7BA5CNFSM4JB434ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4MBNY.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/issues/3111?email_source=notifications\u0026email_token=AFTOJKZUKMFQA5D4RF2K4J3QPZR7BA5CNFSM4JB434ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4MBNY#issuecomment-544784567",
"url": "https://github.com/quicwg/base-drafts/issues/3111?email_source=notifications\u0026email_token=AFTOJKZUKMFQA5D4RF2K4J3QPZR7BA5CNFSM4JB434ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4MBNY#issuecomment-544784567",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5dae6c70812f4_2bd73fb1202cd95c1022cc--