[quicwg/base-drafts] Authenticating connection IDs (#3439)

Martin Thomson <notifications@github.com> Thu, 06 February 2020 15:18 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE09F1208C7 for <quic-issues@ietfa.amsl.com>; Thu, 6 Feb 2020 07:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El5MALu2nuHm for <quic-issues@ietfa.amsl.com>; Thu, 6 Feb 2020 07:18:24 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6A01208F4 for <quic-issues@ietf.org>; Thu, 6 Feb 2020 07:18:24 -0800 (PST)
Received: from github-lowworker-275fa97.va3-iad.github.net (github-lowworker-275fa97.va3-iad.github.net [10.48.17.64]) by smtp.github.com (Postfix) with ESMTP id 393B1C60E22 for <quic-issues@ietf.org>; Thu, 6 Feb 2020 07:18:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581002303; bh=9uxYro/cgxCgPKAWAhH9b74DwCGGRT27ant3q0cbr58=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ZTFGa2FYqOtnjcd+swZApOak5XwheeFJRy98e9KqMhDWhe7v4Yvjj4/r9aaHsXHYn GgrBsCGlAAoiUIJWSi084mZmbLrAltVmEdeJaYfUzNmncnTpgT1Iqvbuc5DVA7ds0m baXxSDW0PGZNR+8+R1jZb//x3FCWbr+7gqWRWZ9I=
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
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Og1jA082UavNifht29GmexJX1Pk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 15:18:26 -0000

@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