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

Michael D'Errico <mike-list@pobox.com> Sat, 03 October 2020 21:04 UTC

Return-Path: <mike-list@pobox.com>
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 80B873A08A6 for <tls@ietfa.amsl.com>; Sat, 3 Oct 2020 14:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 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, NICE_REPLY_A=-0.213, 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=pobox.com; domainkeys=pass (1024-bit key) header.from=mike-list@pobox.com header.d=pobox.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 RsM7iY7N-IDb for <tls@ietfa.amsl.com>; Sat, 3 Oct 2020 14:04:37 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70F73A0858 for <tls@ietf.org>; Sat, 3 Oct 2020 14:04:36 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 47C0CF4331; Sat, 3 Oct 2020 17:04:34 -0400 (EDT) (envelope-from mike-list@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:to:cc :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1JKRz56YHRK+ HZf9ZXz5G1J194k=; b=QKrYSnz7fWHNbcDL38Rl7fSwoy/m2d4SqPRTVsSeQwIc Qr7tZVpAxN5po10q8yN9yu84usI9MnI69yIaBQgTgjhXQeUADr15iVGcsS91XdP4 dVuNJzMnC9/VQcsrmqpAzdrA+N+7z39gCYZkcQx+Of/Hd+CjyVzyTDbGkTs8r4I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to:cc :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZOu2LT dqvdVoaDAuy/2B3RLLe4HwDPDgdDBlpYBN8+0keRao3eGNl2HiGor1Mq842ISTbD HJ+6AxzAeagL0NWPNyBMmAPSgf7Tb5QXP+/foQCpEA6KhOdDYasvotUshVneW2WL QlB5yITnJ+kLcQMOHlbHKm3ibmGMNmi6Uu8O0=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 40239F4330; Sat, 3 Oct 2020 17:04:34 -0400 (EDT) (envelope-from mike-list@pobox.com)
Received: from MacBookPro.local (unknown [72.227.128.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 624B0F432F; Sat, 3 Oct 2020 17:04:31 -0400 (EDT) (envelope-from mike-list@pobox.com)
To: Nick Lamb <njl@tlrmx.org>
Cc: tls@ietf.org
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> <20201003211257.31450138@totoro.tlrmx.org>
From: Michael D'Errico <mike-list@pobox.com>
Message-ID: <9d504880-72c4-e6bd-7d7b-e809d739b09d@pobox.com>
Date: Sat, 3 Oct 2020 17:04:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <20201003211257.31450138@totoro.tlrmx.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
X-Pobox-Relay-ID: 084AAE5A-05BC-11EB-ABD2-F0EA2EB3C613-38729857!pb-smtp20.pobox.com
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nPTXEhD8b8-GE71zCYjQ1XhGXlY>
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 21:04:39 -0000

On 10/3/20 16:12, Nick Lamb 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.

StackOverflow has only one result if you search for HelloRetryRequest
and it is about jdk.disabledAlgorithms.

When you say it "works just fine" I think you are saying that the
handshake will complete.  But is it secure?  This is the important
parts of "works" and I'm not sure it's possible to do it correctly
without a lot of work, and am certain that a hash is not enough
information even if it's integrity-protected.

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

All the integrity protection bytes tell you is that the server did in fact
generate the cookie at some point in the past.  You don't even know
how old the cookie is if it just contains a hash, unless you are
frequently changing the key (and keeping the previous key around for
a bit to cover the case that the key rollover happened within the life-
time of an old cookie).  A client could possibly exploit this by making
many connections and sending a second ClientHello on each one with
the same legacy_session_id_echo and cookie.  A stateless server might
not be keeping track of whether a cookie is being reused, and why
would it if it's actually stateless?  If it's going to go through the 
trouble
of keeping track of previously-used cookies, possibly across several
distributed machines, why not just be not-stateless and avoid all of
the hassle?

And, yes, it is optimistic to trust a client to do the right thing. It's 
also
dangerous.  I used the word optimistic to downplay the significance.

Rebuilding the beginning of the transcript hash based solely on what
the client sends in its second ClientHello message is fraught with peril.

Mike