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

MikkelFJ <> Fri, 06 March 2020 07:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F30B3A0930 for <>; Thu, 5 Mar 2020 23:46:48 -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 FRSUF0RVec3m for <>; Thu, 5 Mar 2020 23:46:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1BAE3A092F for <>; Thu, 5 Mar 2020 23:46:46 -0800 (PST)
Date: Thu, 05 Mar 2020 23:46:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583480805; bh=gtVQHjOmE2jkr0N8NHCmyMxUuqYaxrCQDIOT27zWpsI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2SwO/w2r/6J+OAFaTbwZ3w+4O7H/3igW/tmgVtEd9ZGB7m/PxMNutvcIzT4mFwmoA Hu8eam6lyoXGYia5Bf5BSvQDJs6JjgJokxfhR8kWwxhHrvMyUn8t+6BYbJ6OYBNk+p JlHgh1EMUBPvr8YUxJ34bPvwmv9XKQUXJ9nWKPAA=
From: MikkelFJ <>
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_5e61ffe59abc3_8863f9f1a4cd968222773"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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 07:46:49 -0000

I think @huitema makes a lot of good points. However, tying ODCID to retry-CID could make the production DCID longer than is desirable.

Another option might be to have an additional authentication tag (AAT) in the handshake packets that is carried along similar to TP, but not necessarily inside the TP machinery. The server or LB could check the AAT at high DoS load without forcing the CID to be long and it could cover other critical parameters as well.

If the client needs similar assurances it cannot use th AAT directly to do its own checking, but philosophically, the server decides the CIDs going towards the server, and it is the servers responsible to design and check those CIDs with reasonable security bounds for the given deployment. If a server does not check for retry attack CIDs, there are many other things that it might also not check making the connection flawed in some way.

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