IETF Logo Mail Archive

Re: [TLS] PQC key exchange sizes

"Kampanakis, Panos" <kpanos@amazon.com> Wed, 27 July 2022 18:56 UTC

Return-Path: <prvs=2006fe077=kpanos@amazon.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 897C3C157B33 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2022 11:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.189
X-Spam-Level:
X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
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 tIzr4mkytpum for <tls@ietfa.amsl.com>; Wed, 27 Jul 2022 11:56:50 -0700 (PDT)
Received: from smtp-fw-9103.amazon.com (smtp-fw-9103.amazon.com [207.171.188.200]) (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 15A86C14CF17 for <tls@ietf.org>; Wed, 27 Jul 2022 11:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1658948210; x=1690484210; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=unOykkYEIPgdjykDWEFJ5EX4nd7NCrjjhmRxDj4qZZ0=; b=AUNNsrlADFxulNhDi9V/6xV8oIkfG53Y5Acs1wiTjXlbutEbndr1zIeU TYi1CWJzPUz1koBuHpr1WTOd2xXN7GCT8Ihn2/4b6IXxlIwDuK/MIUpln 0DvQUrXE6RR7WYJi02NFRFrV6in3kZSi0OEWt9avMETV1N7xgHhNm9+ZB 4=;
X-IronPort-AV: E=Sophos;i="5.93,196,1654560000"; d="scan'208";a="1038460008"
Thread-Topic: [TLS] PQC key exchange sizes
Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-iad-1a-a31e1d63.us-east-1.amazon.com) ([10.25.36.214]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2022 18:56:30 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1a-a31e1d63.us-east-1.amazon.com (Postfix) with ESMTPS id 988005E0FE8; Wed, 27 Jul 2022 18:56:29 +0000 (UTC)
Received: from EX19D001ANA002.ant.amazon.com (10.37.240.136) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Wed, 27 Jul 2022 18:56:28 +0000
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX19D001ANA002.ant.amazon.com (10.37.240.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.9; Wed, 27 Jul 2022 18:56:27 +0000
Received: from EX19D001ANA001.ant.amazon.com ([fe80::6054:a5f0:5f79:c120]) by EX19D001ANA001.ant.amazon.com ([fe80::6054:a5f0:5f79:c120%5]) with mapi id 15.02.1118.009; Wed, 27 Jul 2022 18:56:27 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Index: AQHYoQFNhppuch2xgEOt7202I6P1U62RfakggADOQICAAEW94A==
Date: Wed, 27 Jul 2022 18:56:27 +0000
Message-ID: <0bebb6b80caa4ad6804b94bb74959675@amazon.com>
References: <CABzBS7nsbEhR-bmHG_ViSJFSH-0_5p0O3vKndS4+wFR=iGQzhw@mail.gmail.com> <YuABORXSaes9Wqwo@LK-Perkele-VII2.locald> <a643450d5fdb40cf8af3f5b96cdbd922@amazon.com> <YuFOm9bUWkPBOBw3@LK-Perkele-VII2.locald>
In-Reply-To: <YuFOm9bUWkPBOBw3@LK-Perkele-VII2.locald>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.43.157.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TCtq-1tpfmjMn4nq5ESoUw0kU0A>
Subject: Re: [TLS] PQC key exchange sizes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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, 27 Jul 2022 18:56:51 -0000

Gotcha. This is a reasonable explanation for a potential problem, but I would also like to see experimental proof that DTLS implementation X, Y, Z have the problem. TLS implementations don't deal with big ClientHellos today so we could assume they would have a problem, but when tested they do OK for the most part.
 

-----Original Message-----
From: TLS <tls-bounces@ietf.org> On Behalf Of Ilari Liusvaara
Sent: Wednesday, July 27, 2022 10:42 AM
To: <tls@ietf.org> <tls@ietf.org>
Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Wed, Jul 27, 2022 at 02:27:12AM +0000, Kampanakis, Panos wrote:
> Hi Ilari,
>
> > - DTLS-level fragmentation. There are buggy implementations that
> >   break if one tries this.
>
> DTLS servers have been fragmenting and sending cert chains that don’t 
> fit in the MTU for a long time. Is this buggy on the TLS client side?

These problems are specific to fragmenting Client Hello. Handling fragmented DTLS Client Hello is different from handling fragmented DTLS Certificate (and even more so in DTLS 1.3). I think DTLS specification just pretends both cases are the same. They are not.


QUIC implementations could have similar issues with multiple initial packets, but operating QUIC with fast failure-independent fallback would make failures soft.


There is the general principle that if some protocol feature is not used in the wild, it tends to break, even if required part of the protocol. Either by implementation being poorly tested and buggy, assuming the feature does not exist, or being missing entierely.
Combine this with interop failures having outsize impact and old versions sticking around far longer than desriable. And I do not think fragmented Client Hellos in DTLS or multiple initials in QUIC are seen much.


One trick with DTLS would be sending client hello with no key shares. Causes extra round-trip, but any server that selects PQC causing fragmentation would presumably be capable of handling that.



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email