Re: [New Issue] Inconsistent behavior with NCIDs

Martin Thomson <mt@lowentropy.net> Sun, 06 December 2020 23:31 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12303A0D38 for <quic@ietfa.amsl.com>; Sun, 6 Dec 2020 15:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=sR4AuUa5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pfLktF2Z
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 TVWUajfL2V0h for <quic@ietfa.amsl.com>; Sun, 6 Dec 2020 15:31:18 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE3C3A0D09 for <quic@ietf.org>; Sun, 6 Dec 2020 15:31:18 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4EB10683 for <quic@ietf.org>; Sun, 6 Dec 2020 18:31:17 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 06 Dec 2020 18:31:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=87vOjcl3106HNCmzyAGRu834+XpwYhf oCgLomxkQt2A=; b=sR4AuUa5IPRiGYalW0JTjAE2W9qEsuRpNd29XYF1kYuk+zs SQNrpL+i7vSphNTvDcdI5ezaSAOSPO7/gadk/6u4tgFegN21zMThkbro3d6Vxj7m shNedPoi9gMSCKpRKX4Bb0BdQyVpMNlo9Jsj9Tub6uh3jTmDDB+56MBjek4LqmCc I8NEPiPz4tdSNoAR/rxnIvakInTAjaTs7V3+SD6LOwDQaqqhEId5owqsSyDyr5rD SfQ7kFoHKGnKJNpaRqwYhWX81NR35Jxx480s3sHiMWO/KtxR7Nne52IqOKrgR0Ah qOAOZQvMdLCR+diDo7h4aXpkgBcqlVmFgur2GZA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=87vOjc l3106HNCmzyAGRu834+XpwYhfoCgLomxkQt2A=; b=pfLktF2Zbt3ICiMVwf360I BbRp2vfOiiQfNqqMd/ddlXQ7g4sdFe+2v2vDFeub6ijZIC1iX7Toj9GL6D3Lqoww MBg8c80BpGGWeqytw98DDgi83SA9XADeMxabIJN/6c4nVaZ1b08tVPu0B71RR6iJ EmN4SpxuAqZQnNsY17WKbX+Ox+MEWD7dHvdGrlRIMnAI+ejfV584uWlCMr0wgNcK 7coLnx+pfV/Mt6X6PvdU00SmD0BmOlPLygHaGwXB+3KaOIKKvuuSb5ZgHNWFwifA bBAd3qNw6SsWwCF6aYHzKRfWys5TafbxaUj9HhNngq0XW2uVWJIgjAJ0uEId9XdQ ==
X-ME-Sender: <xms:xGnNX_tILAOpJWsBbfSc0lqPW_z2Fw5pmA82SXu9PhoJp9A7oyJXQA> <xme:xGnNXwexxlyhL37pWpkC_djx14TFW8riddkq6Tbgaz2V1-KhnzfJdNOhWb5cEV4n5 F5e0i-yhZCD4hYujjY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejfedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:xGnNXywCej-bWCq3X2coA5CgWUdQpN9gx_7lxhR2muhdCy8sznkEMw> <xmx:xGnNX-PgWRJ0pm2ucwQZlhr8y1RUVDHzMVXYydQTeLfQ4g2kCg858A> <xmx:xGnNX_922Pc-sIjpSgU2VX4bkyeomA4bn_RJKzHGG90tqlaePcOD7g> <xmx:xGnNXyK4oOeD-cajXdoW9B4__SKiHengZ5yOBtw6-ty_RVOdy-l09w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8C8D0200C4; Sun, 6 Dec 2020 18:31:16 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <b7a94f68-585d-405f-84bd-f5d31572bf1c@www.fastmail.com>
In-Reply-To: <8e5c1ef0-4b11-b992-67cf-b7fd4b079b9f@informatik.hu-berlin.de>
References: <339bd591-85a3-35e8-10b0-b4355be29469@informatik.hu-berlin.de> <09b773d0-3f06-403b-a359-c1ee9a0f6ad5@huitema.net> <8e5c1ef0-4b11-b992-67cf-b7fd4b079b9f@informatik.hu-berlin.de>
Date: Mon, 07 Dec 2020 10:30:56 +1100
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: [New Issue] Inconsistent behavior with NCIDs
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6mNyrwT57NZTHNjmy9pfJnSH_9U>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Dec 2020 23:31:20 -0000

On Thu, Nov 26, 2020, at 00:32, Kashyap Thimmaraju wrote:
> I agree that the privacy of one end-point relies on the other end-point.
> However, I'm actually refering to cases where multiple CIDs are shared 
> within an
> NCID frame. This is definitely not good for both end-points, as this enables
> linkability of the QUIC connection. How could this be used? Well the 
> attacker
> can simply link the flow after connection migration or by observing it for a
> long time. Does she gain anything else? I can't think of other gains.

There should be no case where an endpoint has concurrent use of connection IDs with the same value.  Whether that is as a result of receiving them at the same time or not.  Implementation should be able to detect that case and the specification encourages the use of CONNECTION_CLOSE if that is detected.  However, we cannot require more thorough checking for the aforementioned reasons.

As I said before, different values are not sufficient to prevent linkability if a peer is determined to cooperate with an attacker, so I see no value in pursuing that.  Same for questions of covert channels.