[TLS]Re: Meta deploying -hybrid-design

Martin Thomson <mt@lowentropy.net> Tue, 13 August 2024 12:37 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 B2CF5C15199A for <tls@ietfa.amsl.com>; Tue, 13 Aug 2024 05:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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="CynAzMI6"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="OqVfU3/W"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtmDkTLCgjmS for <tls@ietfa.amsl.com>; Tue, 13 Aug 2024 05:37:34 -0700 (PDT)
Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0872C151980 for <tls@ietf.org>; Tue, 13 Aug 2024 05:37:33 -0700 (PDT)
Received: from phl-compute-05.internal (phl-compute-05.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id F1DD2138FDA1 for <tls@ietf.org>; Tue, 13 Aug 2024 08:37:32 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by phl-compute-05.internal (MEProxy); Tue, 13 Aug 2024 08:37:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1723552652; x=1723639052; bh=Jy/BLfPKVqurylAPTN2pK/CGl6hh90wVHmH8kCWPx2Y=; b= CynAzMI6mDqpwE32Ag9ANYGPHKnVM/A2fdWLyclKX8EoJNEQroGeCtgmYHBPEgnN lEE9fPtYfqVF0mMQ2OnopOub5EvQ9qbSXQoAx112qygZsP2biqb/HrIHP4Klif/r GjQYtIfYVEeb8+vUQStpqrSP8EyIxbaO1x5k6WBi6Hmf9q1zDQ9/3b3n68S15gDd dDkGJOEK8Ylciwim4FSHqzBkfwopPxEtIhqxsQIMfIn2Ty5jXyOx26+ayRHecDaj ZECzB1jHLTTA+BYr7igDvohX5zFr+OrOIHEMimGr4wOoBhN8yA/n26ABS3dM/pxn iKvftmdQs1lv/B0h0epbNg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1723552652; x= 1723639052; bh=Jy/BLfPKVqurylAPTN2pK/CGl6hh90wVHmH8kCWPx2Y=; b=O qVfU3/Wdhz/3H0UGvsHyo5Ro9Ov88dhVJOlh/oto34SnPJVB++Qr7i7o3Cq4f/zI bQNi/P3zZwKGLOOc+7FqJKNUvNxre7pbpxmuTMJjULowWXYIQ6qQDEHdaWoOHLY/ 6h9OZdoKvzH0fA/qAmQP2u9GKTSHbj/PcHJW9hoa57Qk5dId01hOWjp3ALlKNqEn 07gGfWxMMOsLEvjJLV7z9vVi0C4HE1PCkK/d7jfmaUz06ARrD3uuWwv1/CnoxadJ 2MaWLWAHnPYOImHpIlLZ5LpQ5WhB89eNo8MOC9ZispHEYkgHnXnB8E3Z2Pcv32WF U+YKAgoXE1I+fOXAlhXfw==
X-ME-Sender: <xms:jFO7ZoqSaNxqunTNXDKx10vtD6KvGST4Yy_YyXbCp19nMtCMrCk7Jg> <xme:jFO7Zup8XNdgJyeGOviR0T6CJpChvabMylZ9bwCACZ5vvw_4GWKrb_X0N3o4Kvavq 9yFTBKKDL4H7B-eyUw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddtvddgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhs ohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpe etteefiedvfedutdekhfeljeejtdduleffueehhfefhedutdetfedvgefhffevkeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhu thdprhgtphhtthhopehtlhhssehivghtfhdrohhrgh
X-ME-Proxy: <xmx:jFO7ZtPDs9VatzlJQcJwpfSD1pw7a9OXs4C3dwEQ7gWNt43K8RCdKQ> <xmx:jFO7Zv5e4URSF1rNWF-soI1dUe35p4zce0F4YiQUDUVxBMM7FCd_2A> <xmx:jFO7Zn5queFg7KveCFR9QoeL69HXX8auXHMP4RnjEIYH9zYCKjtcGQ> <xmx:jFO7ZvgnrqKezPv5ZZH5u0uAFZonKC5g63_u_-4LmN8-BrDmGgSmvg> <xmx:jFO7ZkhomLVdJCvuAAISlA4WEO8k_X21Q7Tdu6HRb5YAkbdzyabMhGSD>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BDE4E2340081; Tue, 13 Aug 2024 08:37:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
Date: Tue, 13 Aug 2024 13:36:52 +0100
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Message-Id: <3e2bd914-a10d-4393-a116-cdb968fbc5fc@app.fastmail.com>
In-Reply-To: <CAFR824xj7tkQObS3QBrxm36THCRqBjm1KDjpgZpu3Ay-0HHzgg@mail.gmail.com>
References: <CAFR824xj7tkQObS3QBrxm36THCRqBjm1KDjpgZpu3Ay-0HHzgg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: B75WVRLLJOB4YUCFM7KA5VIDL4FWCSRV
X-Message-ID-Hash: B75WVRLLJOB4YUCFM7KA5VIDL4FWCSRV
X-MailFrom: mt@lowentropy.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Re: Meta deploying -hybrid-design
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zy0dCaU7XS22NAzMFtj0eEC_OpA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Mon, Aug 12, 2024, at 17:49, Deirdre Connolly wrote:
>> In the future, an increase in MTU, or utilizing QUIC, which allows for multiple initial packets, may allow for larger ClientHellos without an additional round trip.

This demonstrates a very common misconception about TCP.  I know that some implementation choke if the TLS ClientHello spans multiple TCP segments such that it requires multiple reads.  David Benjamin has written about this several times.  It's rare though and a bad basis to make decisions on.

>> To address this, we had the client split each service into different TLS session scopes – one using classical key exchange, and one using hybrid key exchange. Each session scope thus uses only one named group each, avoiding the keyshare thrashing behavior described above. The tradeoff is space consumption due to having to store more session tickets, but this has been acceptable given the small size of each session ticket (a few hundred bytes).

This smells proprietary.