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

martinduke <> Thu, 05 March 2020 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B6E63A088E for <>; Thu, 5 Mar 2020 09:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 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_IMAGE_ONLY_28=1.404, 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 Ao3_HDWRtuFM for <>; Thu, 5 Mar 2020 09:55:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9ABA43A088C for <>; Thu, 5 Mar 2020 09:55:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 72D106608A6 for <>; Thu, 5 Mar 2020 09:55:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583430941; bh=9WkTBbvDD6MaaZOHIM4nbzwf+Ed+2/j5PXKvupo6Hts=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=L60rMBoanxq1tolWa4kqSt0ig9S5KD38Qsu9o769SmA0fxGkPwiCHlmt9k7PizTBS J8kHPfUNqAfkPOU7op8DNv/359vNGwCFKIGnO/Ln9ExtyKr/luqWIGXHxQw22DcLV/ kv3RthYRHagoSYASQmfhvz1eVpzryRVL/mUiND8c=
Date: Thu, 05 Mar 2020 09:55:41 -0800
From: martinduke <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3439/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e613d1d64041_705b3f94a0acd96419143"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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: Thu, 05 Mar 2020 17:55:45 -0000

After skimming the paper and reading MT's justification a few times, I guess I am still unclear on the threat model:

1) Attacker rewrites the SCID of a Retry Packet. This affects the Initial Keys and can't be protected by the TP. Server acceptance of the provided CID is a pretty good indication it doesn't much care, in which case, meh. If someone picking a CID will take your site down, change the CID!

If we must do something here, perhaps we should just say "servers MUST change their CID if they are sending an ODCID TP?" -- this would make it easier for Google and minimize the change otherwise.

But really the answer is to put in the token. It's the only way to definitively kill the connection if a MITM is messing with us, and solves the Initial-Key problem.

2) Attacker rewrites the SCID of server initial. Doesn't Section 5.2 mean that the server would simply discard the remaining Client packets? Doesn't this obviate the need for the TP? I guess the MITM could successfully rewrite to the original client-chosen DCID, but presumably servers are written to limit the ability of clients or MITMs to just ignore the new CID?

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