Re: [quicwg/base-drafts] Authenticate connection IDs (#3499)

Christian Huitema <> Fri, 06 March 2020 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A14E13A0FED for <>; Thu, 5 Mar 2020 17:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GRbOUK90eLgx for <>; Thu, 5 Mar 2020 17:05:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C8DC3A0FEB for <>; Thu, 5 Mar 2020 17:05:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 864F85204F5 for <>; Thu, 5 Mar 2020 17:05:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583456744; bh=VIixIHxrbvzcd1iqvSoEByl1CkrjeOL1OoCKwPwgoDM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=W7e3N/PhOdUesA9XM/ELFP7XhLXXSIgOpIwX2D4Et5tN4mKA/bvj3quyBJ4VMRDpo pghH409j2BctkPyqT46Wrm4BRmshj4AKsK+14GN7a/0KUio9ryhfnHa+37yuN/A9DA iIGVf+1FHgxbePWWTWH4ESvdS1H7lVjAwbzs/VmE=
Date: Thu, 05 Mar 2020 17:05:44 -0800
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3499/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Authenticate connection IDs (#3499)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e61a1e8767e3_5b9e3ff7318cd968588b0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2020 01:05:47 -0000

huitema commented on this pull request.

Could we add to this PR a description of the attack, maybe in the security section, and the suggestion that servers may want to tie the retry token to both the ODCID and the server's initial SCID?

>  from the server, it MUST discard any packet it receives with a different Source
 Connection ID.
+Each endpoint includes the value of the Source Connection ID from Initial
+packets it sends in the handshake_connection_id transport parameter; see
+{{transport-parameter-definitions}}.  Each endpoint validates that the value
+received from the peer is identical to the value of the transport parameter.
+Absense of the handshake_connection_id transport parameter or a mismatch in
+values MUST be treated as a connection error of type PROTOCOL_VIOLATION.  When
+sending a Retry packet or the first Initial packet, a server MUST select values
+for the Source Connection ID field that differ from the values the client
+includes in the Destination Connection ID field.  These measures ensure that the
+choice of connection ID cannot be influenced by an attacker.

I have some difficulty parsing that in the retry scenario. is "the Source Connection ID from Initial
packet" the value found in the retry packet sent by the server, or is the source connection ID in the first initial packet of the server? Currently, there is no requirement that these two be the same value.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: