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

Martin Thomson <> Thu, 05 March 2020 06:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BFF93A0E04 for <>; Wed, 4 Mar 2020 22:32:02 -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 vqNMTiKxigNq for <>; Wed, 4 Mar 2020 22:32:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 020F63A0E03 for <>; Wed, 4 Mar 2020 22:32:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 95850C60DAC for <>; Wed, 4 Mar 2020 22:31:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583389919; bh=onh1IxDKw8uidWBDQCE7mepA8ImC/I/YKnc5rDPJFOo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rSQDBY9kC+WqU67ZWfSIxg4xpm9++aIAUk5lhtk7e7KWmNlCmV7fAYxRCXicB+zl4 wpqGfZSj3j3UrUoTryCDI5wTzVHQ1DiviGgDGv1mBLxsufoZWcjsLplgCnlaG2czGH IaCknkPXtVoWFMFVDT0v2Cvu1pMIIBQRlwtIHIDU=
Date: Wed, 04 Mar 2020 22:31:59 -0800
From: Martin Thomson <>
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_5e609cdf87720_10d83fcd69acd96c3066ae"; 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
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 06:32:02 -0000


> I'm not sure we should be discouraging servers from using client-generated connection IDs. We've been doing that for years and I'm not sure there is a credible attack here.

The problem is not with what you are doing, but a consequence of adding Retry to the protocol. In addressing the problems arising from that we can ask servers to make a small sacrifice in terms of requiring them to generate a new connection ID, something they need to know how to do anyway. Or, we can ask clients to conditionally validate server behaviour.

I appreciate that if you have no need to send Retry, this might be an imposition on the server, but from the outside it seems totally doable. I would like to understand less about the strength of your reluctance to offer a new connection ID and more about why it might be difficult to do so.

Is this expensive because you have to consult with load balancers?

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