[TLS] Re: draft-ietf-tls-key-share-prediction next steps

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 11 September 2024 07:57 UTC

Return-Path: <ilariliusvaara@welho.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 EABFFC14F6FB for <tls@ietfa.amsl.com>; Wed, 11 Sep 2024 00:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
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 7hC05UyQ5grJ for <tls@ietfa.amsl.com>; Wed, 11 Sep 2024 00:56:57 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086F0C14F6BA for <tls@ietf.org>; Wed, 11 Sep 2024 00:56:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 44C2B20A90 for <tls@ietf.org>; Wed, 11 Sep 2024 10:56:54 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Z-m08ZtZ6mf0 for <tls@ietf.org>; Wed, 11 Sep 2024 10:56:54 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-153-79.rev.dnainternet.fi [87.92.153.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EE1CF2309 for <tls@ietf.org>; Wed, 11 Sep 2024 10:56:52 +0300 (EEST)
Date: Wed, 11 Sep 2024 10:56:52 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <ZuFNRD6UWgkhAbdl@LK-Perkele-VII2.locald>
References: <CAF8qwaAU+cRapAc3xnySXiq2nOTXAFvLQYdWNC6rXdFj8iA39w@mail.gmail.com> <CAOp4FwTySAHKtwKv4ade9qm19GCvag-PAJxmDndxG5CYsDPvkw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAOp4FwTySAHKtwKv4ade9qm19GCvag-PAJxmDndxG5CYsDPvkw@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: GLP6RZJ765ORINZ2XVK265C4LTZLLPNF
X-Message-ID-Hash: GLP6RZJ765ORINZ2XVK265C4LTZLLPNF
X-MailFrom: ilariliusvaara@welho.com
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: draft-ietf-tls-key-share-prediction next steps
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/1CPhR8Syv_-MKn5718DJszAVgOg>
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 Wed, Sep 11, 2024 at 10:13:55AM +0400, Loganaden Velvindron wrote:
> On Wed, 11 Sept 2024 at 01:40, David Benjamin <davidben@chromium.org> wrote:
> >
> > Hi all,
> >
> > Now that we're working through the Kyber to ML-KEM transition, TLS
> > 1.3's awkwardness around key share prediction is becoming starkly
> > visible. (It is difficult for clients to efficiently offer both
> > Kyber and ML-KEM, but a hard transition loses PQ coverage for some
> > clients. Kyber was a draft standard, just deployed by early
> > adopters, so while not ideal, I think the hard transition is not
> > the end of the world. ML-KEM is expected to be durable, so a
> > coverage-interrupting transition to FancyNewKEM would be a problem.)
> >
> 
> Can you detail a little bit more in terms of numbers ?
> -Did you discover that handshakes are failing because of the larger
> ClientHello ?
> -Some web clients aren't auto-updating ?

The outright failures because of larger ClientHello are actually web
server issues. However, even ignoring any hard failures, larger
ClientHello can cause performance issues.

The most relevant of the issues is tldr.fail (https://tldr.fail/)
where web server ends up unable to deal with TCP-level fragmentation
of ClientHello. Even one PQ key (1216 bytes) fills vast manjority of
TCP fragment (and other stuff in ClientHello can easily push it over,
as upper limit is around 1430-1460 bytes). There is no way to fit two
PQ keys.

Then some web servers have ClientHello buffer limits. However, these
limits are almost invariably high enough that one could fit two PQ
keys. IIRC, some research years back came to conclusion that the
maximum tolerable key size is about 3.3kB, which is almost enough for
three PQ keys.

Then there are a lot of web servers that are unable to deal with TLS-
level fragmentation of ClientHello. However, this is not really
relevant, given that the limit is 16kB, which is easily enough for
10 PQ keys and more than enough to definitely cause performance issues
with TCP.


And it is possible for web server to offer both, so even with hard
client transition both old and new clients get PQ coverage.




-Ilari