IETF Logo Mail Archive

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

Michael D'Errico <mike-list@pobox.com> Wed, 30 September 2020 17:21 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 BE9983A0B64 for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 10:21:07 -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 M1WQyS2AZGm6 for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 10:21:03 -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 255063A0BC0 for <tls@ietf.org>; Wed, 30 Sep 2020 10:21:02 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 9399B8FBAC for <tls@ietf.org>; Wed, 30 Sep 2020 13:21:01 -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=ZE8h82HC/+5+ QBWpOGK4GsJYcwk=; b=SO3U/pjSKZ7vLEreOmUboLTvivCcy4X98M8HvLtZDr/L I0sSHVEG3MROpcZZ2stJ6lJ9T4T5qzk+Pdjz2SfEwDqDA07quq/h4bku76GkMEzl 5XVIPWJ2a5CX44SVtaVf5GdDx+MAd6zpt1U+5CMzsc19RcrKY4UH1NndWS4fhIk=
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=VgKZr2 MlwnOPt6iMjPDik6WkafU922/ayRjwdtgymKhenqtrai+rLOQPu7PAtA8DAATVBo brw5BzrFTlAAs4G0yS799GHy7zLXryfZlou7qdkgq3MLW4+0UxEIDXFN3NhYBfhV pTaVK+XFFhOZlrg7XFvgLYWzwP4p+kUVcY0/A=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 8B1488FBAB for <tls@ietf.org>; Wed, 30 Sep 2020 13:21:01 -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 7DE3C8FBA9 for <tls@ietf.org>; Wed, 30 Sep 2020 13:21:00 -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> <24f5cd7e-4fff-ce47-f9d9-840dff3f23aa@pobox.com> <3b48fa2d-f923-40ee-a93f-e0896a96fc1b@www.fastmail.com> <ba70c2ba-9023-4cc8-974a-01a64a60de2d@www.fastmail.com>
From: Michael D'Errico <mike-list@pobox.com>
Message-ID: <82488341-a4c6-2ed9-d8e2-6479151a5f90@pobox.com>
Date: Wed, 30 Sep 2020 13:20:59 -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: <ba70c2ba-9023-4cc8-974a-01a64a60de2d@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
X-Pobox-Relay-ID: 4F71C0F2-0341-11EB-8C87-2F5D23BA3BAF-38729857!pb-smtp2.pobox.com
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/A6_YvjjYSdPqkBSX_pUxhASmVHQ>
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 17:21:08 -0000

 > 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
ClientHello message is trivial.  But if doing stateless HRR has
measurably increased the performance of a data center's web
serving capability, I'll change my mind about it.

 > We also implement DTLS where this is properly useful.

I can't find the DTLS 1.3 spec.  Which RFC is it?

Mike

v2.29.0 | Report a Bug | By Email | System Status