Date: Thu, 06 Feb 2020 07:18:23 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJK7QTUFHXT3ACBW2T254JFQL7EVBNHHCC4LIRI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3439@github.com>
Subject: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5e3c2e3f34077_3b6b3f80fb0cd968201553";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Og1jA082UavNifht29GmexJX1Pk>


----==_mimepart_5e3c2e3f34077_3b6b3f80fb0cd968201553
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@ad-l has noted in the past that we don't authenticate the connection IDs that are exchanging during the handshake.  This complicates analysis of header protection (for details, see the upcoming paper).  We already authenticate the connection ID that the client first uses if there is a Retry packet sent, but we don't otherwise authenticate the connection IDs that are signaled in the Source Connection ID field.

The question here is whether we should be more careful about authenticating these.  

@nharper also points out in #3429 that the ODCID transport parameter is an odd duck.  If we use transport parameters to authenticate connection IDs, we might be better served by restoring a fixed header to the transport parameters so that we can more cleanly address that issue.

-- 
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/3439
----==_mimepart_5e3c2e3f34077_3b6b3f80fb0cd968201553
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/ad-l/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ad-l">@ad-l</a> has noted in the past that we don't authenticate the connection IDs that are exchanging during the handshake.  This complicates analysis of header protection (for details, see the upcoming paper).  We already authenticate the connection ID that the client first uses if there is a Retry packet sent, but we don't otherwise authenticate the connection IDs that are signaled in the Source Connection ID field.</p>
<p>The question here is whether we should be more careful about authenticating these.</p>
<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/users/nharper/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/nharper">@nharper</a> also points out in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="560867244" data-permission-text="Issue title is private" data-url="https://github.com/quicwg/base-drafts/issues/3429" data-hovercard-type="issue" data-hovercard-url="/quicwg/base-drafts/issues/3429/hovercard" href="https://github.com/quicwg/base-drafts/issues/3429">#3429</a> that the ODCID transport parameter is an odd duck.  If we use transport parameters to authenticate connection IDs, we might be better served by restoring a fixed header to the transport parameters so that we can more cleanly address that issue.</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/3439?email_source=notifications&amp;email_token=AFTOJK2TFLITGOC24FJOLUDRBQS37A5CNFSM4KQ6X5HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILRNCFA">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK3IDRMRTXZDS6HWYALRBQS37ANCNFSM4KQ6X5HA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJK4AZ3GC47I4HP23DF3RBQS37A5CNFSM4KQ6X5HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILRNCFA.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/3439?email_source=notifications\u0026email_token=AFTOJK2TFLITGOC24FJOLUDRBQS37A5CNFSM4KQ6X5HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILRNCFA",
"url": "https://github.com/quicwg/base-drafts/issues/3439?email_source=notifications\u0026email_token=AFTOJK2TFLITGOC24FJOLUDRBQS37A5CNFSM4KQ6X5HKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILRNCFA",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5e3c2e3f34077_3b6b3f80fb0cd968201553--