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