Date: Tue, 10 Apr 2018 04:15:20 +0000 (UTC)
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abab37c455c61338acaf78e3f682c70d469efe6caf92cf0000000116e3fc5892a169ce12414b9e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1230/379968590@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1230@github.com>
References: <quicwg/base-drafts/issues/1230@github.com>
Subject: Re: [quicwg/base-drafts] Stateless Reset needs "on-path" proof (#1230)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5acc3a587be76_12573fcdfd3c6f304006e3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/MpXxHr2ZyMEqi_Dnxsh_CpKCF3k>

----==_mimepart_5acc3a587be76_12573fcdfd3c6f304006e3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

OK, thanks for clearing that up.  I think that you have an attack, though it might not be that interesting.

Connection IDs are scoped to a state store, whereas your proposed key is global.  That means that an attacker that can learn the key for a given connection ID in any state store can use it to attack all other state stores.  For high entropy connection IDs, that takes some doing, but it isn't generically safe, especially now we allow as little as 32 bits.

What is generically safe is co-extant state.  That is, the connection ID has to be valid everywhere the static key is used and thus a packet with a given connection ID either causes a valid stateless reset for that connection or it is accepted.

Given the complexity of the additional mechanism and that exposure, I'd rather concentrate on the attack that this issue was originally raised to address: the absence of a proof-of-receipt in the stateless reset packet.  Given that we now have a little as 32 bits of entropy (or less) in a connection ID, the potential for a stateless reset oracle is bothering me a little.

-- 
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/1230#issuecomment-379968590
----==_mimepart_5acc3a587be76_12573fcdfd3c6f304006e3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>OK, thanks for clearing that up.  I think that you have an attack, thoug=
h it might not be that interesting.</p>
<p>Connection IDs are scoped to a state store, whereas your proposed key is=
 global.  That means that an attacker that can learn the key for a given co=
nnection ID in any state store can use it to attack all other state stores.=
  For high entropy connection IDs, that takes some doing, but it isn't gene=
rically safe, especially now we allow as little as 32 bits.</p>
<p>What is generically safe is co-extant state.  That is, the connection ID=
 has to be valid everywhere the static key is used and thus a packet with a=
 given connection ID either causes a valid stateless reset for that connect=
ion or it is accepted.</p>
<p>Given the complexity of the additional mechanism and that exposure, I'd =
rather concentrate on the attack that this issue was originally raised to a=
ddress: the absence of a proof-of-receipt in the stateless reset packet.  G=
iven that we now have a little as 32 bits of entropy (or less) in a connect=
ion ID, the potential for a stateless reset oracle is bothering me a little=
.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/issues/1230#issuecomment-379968590">view it on GitHub</a>, or <a h=
ref=3D"https://github.com/notifications/unsubscribe-auth/AWbkq8IExrrxUxMeu9=
yy2BbYVslkk__Nks5tnDHYgaJpZM4SvUhf">mute the thread</a>.<img src=3D"https:/=
/github.com/notifications/beacon/AWbkq6_tReTwJMjyJOWzuVxL8HKap4dQks5tnDHYga=
JpZM4SvUhf.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/issu=
es/1230#issuecomment-379968590"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name=
":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates=
":{"snippets":[{"icon":"PERSON","message":"@martinthomson in #1230: OK, tha=
nks for clearing that up.  I think that you have an attack, though it might=
 not be that interesting.\r\n\r\nConnection IDs are scoped to a state store=
, whereas your proposed key is global.  That means that an attacker that ca=
n learn the key for a given connection ID in any state store can use it to =
attack all other state stores.  For high entropy connection IDs, that takes=
 some doing, but it isn't generically safe, especially now we allow as litt=
le as 32 bits.\r\n\r\nWhat is generically safe is co-extant state.  That is=
, the connection ID has to be valid everywhere the static key is used and t=
hus a packet with a given connection ID either causes a valid stateless res=
et for that connection or it is accepted.\r\n\r\nGiven the complexity of th=
e additional mechanism and that exposure, I'd rather concentrate on the att=
ack that this issue was originally raised to address: the absence of a proo=
f-of-receipt in the stateless reset packet.  Given that we now have a littl=
e as 32 bits of entropy (or less) in a connection ID, the potential for a s=
tateless reset oracle is bothering me a little."}],"action":{"name":"View I=
ssue","url":"https://github.com/quicwg/base-drafts/issues/1230#issuecomment=
-379968590"}}}</script>=

----==_mimepart_5acc3a587be76_12573fcdfd3c6f304006e3--