Re: Going STEK-less with QUIC?

Martin Thomson <mt@lowentropy.net> Wed, 28 July 2021 06:43 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 CA8ED3A1FEA for <quic@ietfa.amsl.com>; Tue, 27 Jul 2021 23:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=nTccY1xt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Cc4oY6uL
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 Bx9NRFuSjjFy for <quic@ietfa.amsl.com>; Tue, 27 Jul 2021 23:42:55 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600DF3A1FE8 for <quic@ietf.org>; Tue, 27 Jul 2021 23:42:55 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BE47E5C00E3; Wed, 28 Jul 2021 02:42:52 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Wed, 28 Jul 2021 02:42:52 -0400
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=fm2; bh=OpBldcnbo2/643WMxIezDxSGvyKUi2M 1XvYvBhl+XII=; b=nTccY1xt85s617mOzwS4Dy14/QmEdQtUTTrJwp6G0VQoDcO dMKyy1Rcq03P5LekBXFdKptRzp4AkP7bUexr6sG+CM9aNSYEh0slJbRhumESrj2S U9JwrWpPoJLM5BV3ZqwMzH0chHTLp9xuATRep5dDRIt7EpIBh6c3eLAYVFJ8/qnk MwNwVx3QoBvgkcU4nBppMlPgHaURaYmQPL0ByZB4sYdaf5bjIdU7m+RSIE/UqsCS VBZDQZhbAOZ2SAUuyqgYp1rdfcXidlC8GjbGEGDUtDjovR8I+cBGrAA2i43S8LKW BHIBgGb6wUGw6hFREZd9LDmBZfVsrMppI99O0XA==
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=fm3; bh=OpBldc nbo2/643WMxIezDxSGvyKUi2M1XvYvBhl+XII=; b=Cc4oY6uLBtM5O1r/m0G1an siMYdtPcv+t0B0k1pjHWr8GDWQzM2ya5HE53g5Ar1OSlQbb6o5RYLaLB0J1FUnKn uUaz7SwjYQfPAIVk9nK4EYGtFQhO4BTv2h+g2Wzsr1a1vDrxhAzy8P60J9Mv7ssG KILMdBWBMFHTzU0ts54wgZQA2AwFiD+xEsqpa9K1UR5QUPyEQfayjOjgDdmelM9f DzTXUkkraFqsGcUv7euy3AdHpopQlPYl5mzP1jtszUi9kAeltYrlnLPlcm7ll/LL sAte0gf+TDhX3KQhDu7FaFg/gJNsmyV1LaNxxZeTgDDfWOASqQfv1y1T4Yv7Ij0A ==
X-ME-Sender: <xms:a_wAYdNDSqlQvoFjBpYz33ufLE3FaDBbHHK--mwAlGZAbShWWXumoQ> <xme:a_wAYf-OCJZ5Q-Q8C5510OBFToHD7FnAmHBrU-nh6OqMX4BOlNZ3FQZuFQZMYasU9 qcwYMFbd88y1pE6IZo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeekgdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:a_wAYcRUkn7SqN6ZEunsACv2iakVu14FC7YKWO6P2ixI8ySoxYnCJw> <xmx:a_wAYZubCb5-gd19PCU5IkqA8vctczK7ClD4CtSde0PDig4Yb3IOHQ> <xmx:a_wAYVdHDKVHWFXnrlGnZShDju9Kt-VhaMdtA1s12yDFjTWitiovyg> <xmx:bPwAYboCiiMw642ayMUcCnwAitZpRlNtQWjK4BD2p5v_O9Nafsu86A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C61F13C0C6F; Wed, 28 Jul 2021 02:42:51 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54
Mime-Version: 1.0
Message-Id: <4a7aea30-9013-4550-b5da-27d7e6ad370d@www.fastmail.com>
In-Reply-To: <9beffffb-e7a6-1c57-be8d-a56f3ef2f1e9@huitema.net>
References: <7265bac0-f54b-0e5b-d5b6-572550809f0f@huitema.net> <CANatvzxBKNf+YdNLPwG=QpZv33o0Mp7uRU+N4JQUpYfbDypQkQ@mail.gmail.com> <b89f83f8-951d-4407-a12c-9d9e85e46fe0@www.fastmail.com> <9beffffb-e7a6-1c57-be8d-a56f3ef2f1e9@huitema.net>
Date: Wed, 28 Jul 2021 16:42:36 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Christian Huitema <huitema@huitema.net>, quic@ietf.org
Subject: Re: Going STEK-less with QUIC?
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GEpu1ZBZJgg1DOV1jJxXLQO-UlQ>
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: Wed, 28 Jul 2021 06:43:01 -0000

On Wed, Jul 28, 2021, at 11:55, Christian Huitema wrote:
> [...] reuse one of the NEW TOKENS as Initial CID, [...]

Are you talking about NEW_CONNECTION_ID here?

If you are talking about the client taking a connection ID from an old connection and using that when establishing a new connection, that's an interesting choice.  I don't think it works because it undermines the return routeability check for the subsequent connection.  The server now knows what the connection ID might be.  I can't think of an exploit for that given that the server has already demonstrated that it is on path, but we do pretty much say that the connection ID can't be predictable like that, and there are no firm requirements that the subsequent connection attempt follow the same network path in any way.

I had assumed that the load balancer would be able to identify an initial and then route based on the Token field in that packet, rather than the connection ID.  Maybe that's too complicated, but it is something that could be used without protocol modifications.