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

Antoine Delignat-Lavaud <notifications@github.com> Fri, 06 March 2020 10:21 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 87CB53A0C26 for <quic-issues@ietfa.amsl.com>; Fri, 6 Mar 2020 02:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
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: 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 CBffZ0JbgJzH for <quic-issues@ietfa.amsl.com>; Fri, 6 Mar 2020 02:21:53 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146D03A0C24 for <quic-issues@ietf.org>; Fri, 6 Mar 2020 02:21:53 -0800 (PST)
Date: Fri, 06 Mar 2020 02:21:51 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583490111; bh=QO4+/ANDfQnoAIEPM8OZUFlkNg/yYPk37bFaPYNY6oM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CeIkZgdK/LO2b9aTAm1k7TCYBOmZEq7fT0biwbJeCqvaSeYplzS5GxgcRCkMgOZpK WoecQIKtz1WKTUBKzKWCzs/Zs3MRXtkTYenvzFlhz9r2ZS8flYppey5JewmBc+YxVX +yIcstvbvkylX5qQ1mMNeWjPc/fSMwWMzOdeIObI=
From: Antoine Delignat-Lavaud <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6HVBOJSE3VZ4NBL6N4NYCT7EVBNHHCC4LIRI@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/595702363@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3439@github.com>
References: <quicwg/base-drafts/issues/3439@github.com>
Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e62243f91f04_790e3fc74f8cd95c20081d"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ad-l
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/UWjyW5ZEvdj47rJKAJh_vt7gwrM>
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: Fri, 06 Mar 2020 10:21:55 -0000

> 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.

I disagree, there are not many other things that the client and server can disagree on after the end of the TLS handshake. The idea to consider connection IDs as an unauthenticated connection parameter (just like the IP address and UDP port) that can be used by networking middlebox for DoS/routing is fine, and it's a possible way to close this discussion, but I urge you to carefully consider the privacy impact for the client. It is somewhat pointless to write a formal proof of packet number encryption if it turns out that an active adversary can inject a 20-byte long unique identifier that appears in the cleartext of every packet - imagine if China starts doing that to tag incoming QUIC connections to users, if many servers allow them to (expecting their own middleboxes to do the same thing for legitimate reasons). Of course it is already possible to do that with TCP, but QUIC CIDs are much longer than TCP ports and can be use for pervasive monitoring at a fine granularity. If CIDs are truly negotiated between the client and server, the client has the guarantee that the server CID really comes from the server, and knows that no tracking CID has been inserted on the way. 

-- 
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#issuecomment-595702363