Re: [TLS] TLS 1.3 Problem?

Michael D'Errico <> Tue, 29 September 2020 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B6273A0EA6 for <>; Tue, 29 Sep 2020 08:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
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: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gqodCE2gMXMo for <>; Tue, 29 Sep 2020 08:14:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60CC23A0EA0 for <>; Tue, 29 Sep 2020 08:14:21 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 4CE1D84B59 for <>; Tue, 29 Sep 2020 11:14:20 -0400 (EDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; 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;; 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 (unknown []) by (Postfix) with ESMTP id 453CD84B58 for <>; Tue, 29 Sep 2020 11:14:20 -0400 (EDT) (envelope-from
Received: from MacBookPro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7FA5C84B56 for <>; Tue, 29 Sep 2020 11:14:19 -0400 (EDT) (envelope-from
References: <> <> <> <> <>
From: Michael D'Errico <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
X-Pobox-Relay-ID: 727BB00C-0266-11EB-9B5A-2F5D23BA3BAF-38729857!
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 Problem?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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