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

Martin Thomson <mt@lowentropy.net> Wed, 30 September 2020 12:18 UTC

Return-Path: <mt@lowentropy.net>
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 D1D693A0C8B for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 05:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=LeZPVfja; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fztPNIT3
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 qbxI5W92psfX for <tls@ietfa.amsl.com>; Wed, 30 Sep 2020 05:18:17 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2743A0EB2 for <tls@ietf.org>; Wed, 30 Sep 2020 05:18:16 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0DBB05C01A0 for <tls@ietf.org>; Wed, 30 Sep 2020 08:18:16 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 30 Sep 2020 08:18:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=EZqgm OijfP2u+UdyeFZ4udYQ97+FfjREg7Nw55Ucqlg=; b=LeZPVfjaRyr7yC8RHgnIH 7za2S6V9fq0nZmEyo13s3L0U9QXVp3g9x2+ujTrpkxruZ0dxUkoSjnm6IDXOM0cf aIR+XXMERvPrnJjsEpkd/FDEpmAQNCq3NGf8LMAssjtjtd9n7byQTuB+/pzN9KDv hnet8PXKNFr11YKfPf6gG3KPVFmvaNiDK7IAxfOrB7982s9z3vkzo2Nc2bzjNAuz 3ncpjLegQUEDeKimgkjOxODoLgd+Hw7oJ5xBobQUlTmP22aLch/ekUBKQLSOxRxW pkEyd1pJ6WjI7XZHGHVtmOEQyHSnhqZ15dFpO88Qt/CeN7CV++2vOSzAfdUpGAj6 g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=EZqgmOijfP2u+UdyeFZ4udYQ97+FfjREg7Nw55Ucq lg=; b=fztPNIT3gRIRxgHk32OTzpXUiE/DBZqS4bRJfE9AlQusHHv6KFlUXLQeB dCCEH79aLEJH+XMsupRnkWZi51B86aRtX3ttQ4tKuQDRgBB3Wf0bM+LPt9l7Uol4 lLaB6pn79kUF/aZlgbJWf7vpWtsL4drxv3CwbosLj0x0A4kFXfsRW2jkwNF6wnoB JT8UYQDoQwTAkdat0BoBw5UCU4oYqCCnfVmxqv9fx67qgVC+eMO5/9w7mDvv2EF+ TH0R63ijHLNG5vvw2wvjqjrXK9mzActUd9uVmx+qEkprZrIW19amtEa0Alwjd6dh dknAjWS1eBcTAR4D7IqdmGtMwIq/w==
X-ME-Sender: <xms:h3d0X_BtXQSFKUASrOItmYl4Fi_JriHTvrih0FCFivicC5FUX7U4ZQ> <xme:h3d0X1iLw41muI20W2FJWpB27IhH2lhtLqywBzTo9uFtz_aXTvEN4GVTcl2_b-mx7 3boB4q3EczcPSSssPY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfedvgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefftefgvedvhfdtffehje dufefhhfevhedufefhgfelleetieefgeefgffgleehgfenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:h3d0X6m888ent0v56C_9diEgsVUGGHYrmHZiiHlYduSZzS869BlgCQ> <xmx:h3d0XxyW9txBD57OINevsYfOhSrMAE9jKKX7AkUei0-YiU4LQ5jZbw> <xmx:h3d0X0TW7oUgB49HGms2AzF2uuqVxPtgtZEpZZGOgwFLvwxgt-7Otw> <xmx:iHd0X7emUxe58FAISA1Rd7fZ-pQfldT1z3GopnamvuXJRWnZtdkPxg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9160D2006A; Wed, 30 Sep 2020 08:18:15 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-382-ge235179-fm-20200928.002-ge2351794
Mime-Version: 1.0
Message-Id: <ba70c2ba-9023-4cc8-974a-01a64a60de2d@www.fastmail.com>
In-Reply-To: <3b48fa2d-f923-40ee-a93f-e0896a96fc1b@www.fastmail.com>
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>
Date: Wed, 30 Sep 2020 22:17:53 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g6_AXCo-B2o5a_P13Q8s8yK0q7I>
Subject: Re: [TLS] =?utf-8?q?Is_stateless_HelloRetryRequest_worthwhile=3F_=28?= =?utf-8?q?was_Re=3A_TLS_1=2E3_Problem=3F=29?=
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 12:18:19 -0000

The costs you describe are trivial. And we limit replay with a binding to remote address, and a short timer. But the benefit is mostly down to reduced code variations. We also implement DTLS where this is properly useful. 

On Wed, Sep 30, 2020, at 15:11, Michael D'Errico wrote:
> [I'm resending this with a more appropriate Subject line. --Mike]
> 
> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>