Re: [TLS] TLS 1.3 Problem?
Michael D'Errico <mike-list@pobox.com> Tue, 29 September 2020 15:14 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 8B6273A0EA6 for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 08:14:22 -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 gqodCE2gMXMo for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 08:14:21 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CC23A0EA0 for <tls@ietf.org>; Tue, 29 Sep 2020 08:14:21 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4CE1D84B59 for <tls@ietf.org>; Tue, 29 Sep 2020 11:14:20 -0400 (EDT) (envelope-from mike-list@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rAbIqU6FOolx FjG15VQi/Mcu13E=; b=wlTRXPSMMhoF4Djpx/rcd+TqbJVQA0SDE+PWm+sokaqu ZDM53rViSuwsaDrzrEsqtn5nt2wnfs4FiCTcCD+gcXpyemEjWLAXpihsU7c6dLXN LfwjNnArBJwUzmuPUphwxyhhR0i6Smk3oYbNb+23LMpsxW6+C+XDQ3OEQIhzW34=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZaQd/E jTyNvR1Qdn4GS+KONEqizVUBgqyuBf2Q7AYHrEPXdKjV0w6vaBNU+Q298CL2cuDc ur9kc+QarxJuhPxdia58dVWAZzm3t59nk8omLi7CJTjqhz1DFYj/l74zbVocOxhr Z8MJuQZ9J6ywjdPJqBPn+Eca57cY1YPu39I8c=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 453CD84B58 for <tls@ietf.org>; Tue, 29 Sep 2020 11:14:20 -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-smtp2.pobox.com (Postfix) with ESMTPSA id 7FA5C84B56 for <tls@ietf.org>; Tue, 29 Sep 2020 11:14:19 -0400 (EDT) (envelope-from mike-list@pobox.com)
To: tls@ietf.org
References: <0c31f2d6-5f8e-2fd6-9a1a-08b7902dd135@pobox.com> <AM0PR08MB37164F2D0E0CE5FB6D62D461FA350@AM0PR08MB3716.eurprd08.prod.outlook.com> <1c7e2f31-8a9e-4bd8-9e80-ab18ebeb609f@www.fastmail.com> <CACsn0cmbDz3ML8o5moAacqfXqYQo-Hqi53XQL6UoGYcZBwy-Mg@mail.gmail.com> <96777977-7707-4311-9876-ca3d53f57f3e@www.fastmail.com>
From: Michael D'Errico <mike-list@pobox.com>
Message-ID: <9b2bb784-5895-bc8a-fae5-1c2056972f97@pobox.com>
Date: Tue, 29 Sep 2020 11:14:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <96777977-7707-4311-9876-ca3d53f57f3e@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
X-Pobox-Relay-ID: 727BB00C-0266-11EB-9B5A-2F5D23BA3BAF-38729857!pb-smtp2.pobox.com
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iRlDFE8vrurfk6SmwE8QRX06pso>
Subject: Re: [TLS] 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: Tue, 29 Sep 2020 15:14:23 -0000
>>> Is stateless HelloRetryRequest even being used? If so, how? > NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state, in which case the retained state is compared against the state from the cookie as an extra sanity check. We chose to do this for a few reasons, but one thing is that it encourages us to use the second ClientHello for negotiating everything. OK, so it sounds like you put something similar to a NewSessionTicket (TLS 1.2) in the cookie with enough information to recreate the server state. This is quite a lot more information than just a "hash" as the spec implies. Also, are you sure you want to do this? The design of TLS 1.3 was supposed to make it fast, but creating a pseudo session ticket for every connection requiring a HRR and then validating and decoding it is going to be really slow. And your data center is going to get hotter because your servers will be compute bound instead of memory bound (if they even were). 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