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, 03 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
- [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Ben Smyth
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Richard Barnes
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] HelloRetryRequest question (was Re: TLS… Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Hannes Tschofenig
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Watson Ladd
- Re: [TLS] TLS 1.3 Problem? Rob Sayre
- Re: [TLS] TLS 1.3 Problem? Martin Thomson
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- Re: [TLS] TLS 1.3 Problem? Ben Smyth
- Re: [TLS] TLS 1.3 Problem? mrex
- Re: [TLS] TLS 1.3 Problem? Martin Thomson
- Re: [TLS] TLS 1.3 Problem? Michael D'Errico
- [TLS] Is stateless HelloRetryRequest worthwhile? … Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Martin Thomson
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Nico Williams
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Hannes.Tschofenig
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Salz, Rich
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Benjamin Kaduk
- [TLS] HelloRetryRequest question (was Re: TLS 1.3… Michael D'Errico
- Re: [TLS] HelloRetryRequest question (was Re: TLS… Michael D'Errico
- Re: [TLS] HelloRetryRequest question (was Re: TLS… Benjamin Kaduk
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Rob Sayre
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Salz, Rich
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Nick Harper
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- [TLS] Client attacks on stateless HRR? (was Re: I… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Nick Lamb
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Michael D'Errico
- Re: [TLS] Is stateless HelloRetryRequest worthwhi… Luke Curley