Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)

Benjamin Kaduk <bkaduk@akamai.com> Wed, 30 September 2020 19:50 UTC

Return-Path: <bkaduk@akamai.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 EEB023A0B53 for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 12:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (2048-bit key) header.d=akamai.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 j-3I1IZhl4WJ for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 12:50:15 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7345D3A0B51 for <tls@ietf.org>; Wed, 30 Sep 2020 12:50:15 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 08UJh2cQ019666; Wed, 30 Sep 2020 20:50:15 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=SvRatZmE1uwa07EphzzlUOkiwqWO35nNUU7zdkHpn4U=; b=nS4SyDLa7qiDxdGUe+DJomDBTDansBQw2VI/oVxgbYGBXzTrPyUykERwBHADpGIje13x cICNvkz78tmQ6hJVDCcEd60U3gjthWGzR32swZrMKX1eSmgRGIb8l9I4+V12DQ9A/qlH M/l0Mu63px1feONs1BqYNg6jRKmRxWHpKq7RlFyHybrgb2sFgEbc0+tuRTAyNhkmqRfn BuAi/E5CDmMQTlTtUR/ivmYYRcUP27OSvNrc0Xf6waSFy5TsCyhr0qyCJcAMBxbQPciA RNigynQhhgsd12O2aK0eodTf0xTirMuAqVDGftrHJHhBy+QsuXAgFYchY3KnIDwBwDAX 6w==
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 33sw6cb3ue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 20:50:15 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 08UJnxYm003760; Wed, 30 Sep 2020 15:50:14 -0400
Received: from prod-mail-relay18.dfw02.corp.akamai.com ([172.27.165.172]) by prod-mail-ppoint3.akamai.com with ESMTP id 33t0yxyng7-1; Wed, 30 Sep 2020 15:50:14 -0400
Received: from akamai.com (unknown [172.19.16.134]) by prod-mail-relay18.dfw02.corp.akamai.com (Postfix) with ESMTP id 897B532A; Wed, 30 Sep 2020 19:50:13 +0000 (GMT)
Date: Wed, 30 Sep 2020 12:50:12 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Michael D'Errico <mike-list@pobox.com>
Cc: tls@ietf.org
Message-ID: <20200930195012.GF20623@akamai.com>
References: <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> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <82488341-a4c6-2ed9-d8e2-6479151a5f90@pobox.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_10:2020-09-30, 2020-09-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 bulkscore=0 malwarescore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009300159
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-30_10:2020-09-30, 2020-09-30 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uOQBbe28_cIhQTmLgyPyPqtUvqk>
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: Wed, 30 Sep 2020 19:50:17 -0000

Hi Mike,

On Wed, Sep 30, 2020 at 01:20:59PM -0400, Michael D'Errico wrote:
> > The costs you describe are trivial.
> 
> The general idea among developers these days that CPU
> cycles are free is a huge problem.
> 
> You didn't answer my biggest question, though, which was
> whether you (or anybody else!) has had success using stateless
> HelloRetryRequest to increase the number of connections a
> datacenter can handle due to the fact that the servers were
> memory-bound.  The amount of memory to hold the first

Could you say a bit more about why you think that demonstration
of production-grade usage in (non-D) TLS is needed in order to justify
this portion of the specification?  Note that you can use HRR
without cookie just fine.

The HelloRetryRequest message has to exist in TLS 1.3 in order
to cope with the case where the client's optimistic key_share
is not acceptable to the server, and another round-trip is
needed in order to get key shares for the proper group.

Give that there will be an HRR message, it seems/seemed quite
prudent to build out all the bits that DTLS would need from a HRR,
since we knew DTLS 1.3 was coming in short order, and we want
DTLS 1.3 to be as small a diff from TLS 1.3 as possible.

While you might in theory want to or be able to use TLS 1.3
HRR+cookie to decrease state keeping at the server, that's not (IMO)
the main reason it exists, and so I don't see a need for anyone
to demonstrate that they have done so in order to justify this
portion of the specification.  The text about allowing stateless offload
being a primary purpose for cookie can be true even though it is not
directly utilized in regular TLS.


With respect to the "hash of the ClientHello" question and how much
state is needed, the idea is that the ways in which the second
ClientHello can differ from the original ClientHello are tightly
constrained, such that the original ClientHello can be reconstructed
by the server given the second ClientHello and an honest client.
If the hash of the reconstructed version does not match the hash
saved in the cookie, you assume that some form of attack is underway
and abort the connection.  You can also do fancier things as has
already been described, but that is part of the origin of the "hash of the
ClientHello" text.  (You do also need the hash value to complete the
transcript, as Watson noted.)

With respect to HRR being a weird instance of ServerHello instead of
a "proper" message in its own right, yes, that is weird.  It was
originally a separate message, and then real-world deployment showed
that there were too many deployed middleboxes that would choke on a
new message type, and we had to come up with a *lot* of awkward
hacks to provide "middlebox compatibility mode" (see section D.4).
It seems simpler to make HRR always be the middlebox-compatible version
rather than have two ways to spell it, so that's why it's the way it is.

-Ben

P.S. If you felt like doing some experiments to see how the
stateless HRR affects the memory/CPU balance, it is implemented
in openssl.