Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)

Nick Lamb <njl@tlrmx.org> Sat, 03 October 2020 20:13 UTC

Return-Path: <njl@tlrmx.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA353A02C1 for <tls@ietfa.amsl.com>; Sat, 3 Oct 2020 13:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tlrmx.org
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 VHm57GFmFsq4 for <tls@ietfa.amsl.com>; Sat, 3 Oct 2020 13:13:06 -0700 (PDT)
Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310DA3A0317 for <tls@ietf.org>; Sat, 3 Oct 2020 13:13:06 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 63D5C920A09; Sat, 3 Oct 2020 20:13:05 +0000 (UTC)
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (100-96-12-57.trex.outbound.svc.cluster.local [100.96.12.57]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C5B89920995; Sat, 3 Oct 2020 20:13:04 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|njl@tlrmx.org
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Sat, 03 Oct 2020 20:13:05 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|njl@tlrmx.org
X-MailChannels-Auth-Id: dreamhost
X-Descriptive-Shoe: 46b9a72f40d80b37_1601755985092_2306258495
X-MC-Loop-Signature: 1601755985092:4198407592
X-MC-Ingress-Time: 1601755985091
Received: from pdx1-sub0-mail-a86.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a86.g.dreamhost.com (Postfix) with ESMTP id 1A4837F8E4; Sat, 3 Oct 2020 13:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=tlrmx.org; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=tlrmx.org; bh=DJ58gPI 5Jzlmr9o8GiEYcm4JJmU=; b=SNvVg+7/AqPiI3njMGnF8oogF15f6VYtcdCGWRW i+r6dDeEW1FZXSr/g+mTWwXWIplsk9OPm05H6PNzJoRA8/OHGj89sRDWAP6SFUbI KZV+Ky/EqfsYbcmk3aZPU9enyaIRaYUfG4dZeI9JSKW/9f4hk4VoxDWfXvX5LiW5 25so=
Received: from totoro.tlrmx.org (124.89.2.81.in-addr.arpa [81.2.89.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: njl@tlrmx.org) by pdx1-sub0-mail-a86.g.dreamhost.com (Postfix) with ESMTPSA id EAE637F1F6; Sat, 3 Oct 2020 13:13:01 -0700 (PDT)
Date: Sat, 03 Oct 2020 21:12:57 +0100
X-DH-BACKEND: pdx1-sub0-mail-a86
From: Nick Lamb <njl@tlrmx.org>
To: Michael D'Errico <mike-list@pobox.com>
Cc: tls@ietf.org
Message-ID: <20201003211257.31450138@totoro.tlrmx.org>
In-Reply-To: <a574e534-235e-4202-9046-fb5cd18cce7c@www.fastmail.com>
References: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.com> <CACsn0cmbDz3ML8o5moAacqfXqYQo-Hqi53XQL6UoGYcZBwy-Mg@mail.gmail.com> <96777977-7707-4311-9876-ca3d53f57f3e@www.fastmail.com> <9b2bb784-5895-bc8a-fae5-1c2056972f97@pobox.com> <eaace566-4fe2-4e86-8382-e0583ce43435@www.fastmail.com> <24f5cd7e-4fff-ce47-f9d9-840dff3f23aa@pobox.com> <3b48fa2d-f923-40ee-a93f-e0896a96fc1b@www.fastmail.com> <ba70c2ba-9023-4cc8-974a-01a64a60de2d@www.fastmail.com> <82488341-a4c6-2ed9-d8e2-6479151a5f90@pobox.com> <03ba01d6974e$ffaefe30$ff0cfa90$@gmx.net> <76c30176-f3bf-cc8f-74fb-b875d66e636f@pobox.com> <ABC80E3E-4C18-4290-B13E-50EDC129566B@akamai.com> <bc6251b7-681f-407a-9e30-dc2a430edeaa@www.fastmail.com> <CAChr6Sy_UG2Z1sOvvQSOetkJ5HGUea2SaSAN+kEJu4X-5MeQJg@mail.gmail.com> <2d9ee8e6-892b-4070-8e87-4902e53a5f70@www.fastmail.com> <CACdeXiKo37pUc9J+wMaM8119uMAUCqURRk+2qyGJi_v49twSCg@mail.gmail.com> <a574e534-235e-4202-9046-fb5cd18cce7c@www.fastmail.com>
X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrfeekgddugeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtjeeftdertddvnecuhfhrohhmpefpihgtkhcunfgrmhgsuceonhhjlhesthhlrhhmgidrohhrgheqnecuggftrfgrthhtvghrnhepveeuheeuvddvfeeufeethfeiteehfedufefftefhtdffieefgfevkeffiedtjeegnecukfhppeekuddrvddrkeelrdduvdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepthhothhorhhordhtlhhrmhigrdhorhhgpdhinhgvthepkedurddvrdekledruddvgedprhgvthhurhhnqdhprghthheppfhitghkucfnrghmsgcuoehnjhhlsehtlhhrmhigrdhorhhgqedpmhgrihhlfhhrohhmpehnjhhlsehtlhhrmhigrdhorhhgpdhnrhgtphhtthhopehtlhhssehivghtfhdrohhrgh
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B3yvKS9CLkirAPIQwhogl72Zma4>
Subject: Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2020 20:13:08 -0000

On Fri, 02 Oct 2020 14:15:48 -0400
"Michael D'Errico" <mike-list@pobox.com> wrote:

> > > You can't possibly implement [stateless HelloRetryRequest] the
> > > way the spec suggests with just a hash in a HRR cookie extension.

Lots of people have and it works just fine, so it seems to me that "You
can't possibly" here means something closer to "I still don't
understand how to" and as such would be more appropriate to some sort
of programming Q&A site like Stack Overflow than an IETF working group.

> Many of the fields in HelloRetryRequest are fixed or predictable, but
> the legacy_session_id_echo is not, for example.  Also, relying on the
> client to remind you what the hash of ClientHello1 is seems extremely
> "optimistic" (in my opinion).

The client MUST use the same value for legacy_session_id in its retried
ClientHello. As a result this value will be available alongside the
cookie.

Section 4.4.2 is clear that a hash used this way in the cookie should be
"protected with some suitable integrity protection algorithm". For
example some implementations use an HMAC construction, but you could do
other things here successfully. So in fact this is not especially
optimistic.

Nick.