Re: [TLS] TLS 1.3 Problem?

Michael D'Errico <mike-list@pobox.com> Wed, 30 September 2020 00:30 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 644F93A1455 for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 17:30:33 -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 AR3Kz0yCIX48 for <tls@ietfa.amsl.com>; Tue, 29 Sep 2020 17:30:32 -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 7384C3A144A for <tls@ietf.org>; Tue, 29 Sep 2020 17:30:31 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5F5118909E for <tls@ietf.org>; Tue, 29 Sep 2020 20:30:31 -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=HR3KnAstW37+ mKpQHVcwTx6rWEM=; b=xNYDMenNLw6LS2Z32NmC+TLrGaboYrWkfR1tg2NqnXqs b3Si/rkaGJuydsvXCkYVrwpvTUeA0uVKKRG4fU10pcAgTqeflUm0uqJS3Vd6EuxQ 1pmC6ntW1HzDqywJasKWVP6d7NwOGLN/edSkKTBfEFruuwjgebfXGBOrFbpqm8c=
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=haSKxQ EjF/wLPUcEGcwn2PItIZNQBYbpMtaUfk+ZrXU9aquxKLqduzuw12pfaXm4fHS+Ji pq/A1gducskhmcn9U7j5CRoXANftyOogST3cQaL455cruZHmIVw6ogY2mnaghiZx 0MigRsESx8iOediAt3PBni0q6FMEI7RXDqHfM=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 587AC8909C for <tls@ietf.org>; Tue, 29 Sep 2020 20:30:31 -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 636C489099 for <tls@ietf.org>; Tue, 29 Sep 2020 20:30:30 -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> <9b2bb784-5895-bc8a-fae5-1c2056972f97@pobox.com> <eaace566-4fe2-4e86-8382-e0583ce43435@www.fastmail.com>
From: Michael D'Errico <mike-list@pobox.com>
Message-ID: <24f5cd7e-4fff-ce47-f9d9-840dff3f23aa@pobox.com>
Date: Tue, 29 Sep 2020 20:30:27 -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: <eaace566-4fe2-4e86-8382-e0583ce43435@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
X-Pobox-Relay-ID: 2514CFB2-02B4-11EB-A924-2F5D23BA3BAF-38729857!pb-smtp2.pobox.com
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ymJwzSiga7aoEjj0i10lf54dVy4>
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: Wed, 30 Sep 2020 00:30:33 -0000

On 9/29/20 19:51, Martin Thomson wrote:
> It's symmetric crypto[1]. Hardly worth noting.
> [1] Mostly.  NSS wraps the symmetric key with an asymmetric key so that server clusters can share session ticket encryption keys without needing interconnects.  But encryption or decryption only happens once per instance.

Well, you also need a MAC, right? (encrypt-then-mac)
This requires another key and a bunch of computation.

Then you have to decode the cookie back into the server
state, and then check whether the new ClientHello (CH)
matches the original from the cookie, with possible
changes, making sure that the key_share supplied in
the new CH was in the original CH, checking that the
list of PSK's was not tampered with in invalid ways, etc.
Much of this is required of any handshake involving HRR
even if not stateless.

Seems worth noting.  Have you measured?

And how do you prevent someone from sending an old
cookie back?  If the server is truly stateless....

Did you (or a client) actually have a data center full of
memory-bound servers which are now handling many
more connections using the stateless HRR feature?

I'm not trying to be unkind, I genuinely don't understand
how stateless HRR can be beneficial.

Mike