Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 30 August 2022 14:01 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 7230EC1594A0 for <tls@ietfa.amsl.com>; Tue, 30 Aug 2022 07:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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] 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 GJBv_mTwkpDL for <tls@ietfa.amsl.com>; Tue, 30 Aug 2022 07:01:12 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24387C1594BB for <tls@ietf.org>; Tue, 30 Aug 2022 07:01:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 29FFAC4DA2 for <tls@ietf.org>; Tue, 30 Aug 2022 17:01:08 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 2165BXQfmgIy for <tls@ietf.org>; Tue, 30 Aug 2022 17:01:08 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E7D4528B for <tls@ietf.org>; Tue, 30 Aug 2022 17:01:06 +0300 (EEST)
Date: Tue, 30 Aug 2022 17:01:06 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <Yw4YIqJyejG6szFQ@LK-Perkele-VII2.locald>
References: <e43fc649-3fc6-333b-c44d-55de0627c710@cs.tcd.ie> <Ymz7yncQAnzmp/eL@LK-Perkele-VII2.locald> <38de10e6-ab3c-6ea1-44b7-57057c97e7aa@cs.tcd.ie> <CH0PR11MB5444D7D4F32F195FFB189C10C1679@CH0PR11MB5444.namprd11.prod.outlook.com> <320bb3ca-890b-45c9-b55f-f0d65bdce7be@beta.fastmail.com> <CAMjbhoXMb93+hy3jjHS=BnMekyoksSejEjJwpPHN967RAH_acA@mail.gmail.com> <9f513169-7b45-2be0-13fd-b8aa2d2a2280@amongbytes.com> <31cf9ef9-14df-40d1-aa61-1ff366b1f40b@beta.fastmail.com> <d33f6c42-0f9d-add0-7e98-57e0ceeaa55f@amongbytes.com> <CAMjbhoVodu1shSXs86VkztTt5et2uQsmYCubx3DP+yf8K=N1eQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAMjbhoVodu1shSXs86VkztTt5et2uQsmYCubx3DP+yf8K=N1eQ@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XoLKZK2sQRDCJZ7tD50OYxOdUuM>
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
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: Tue, 30 Aug 2022 14:01:16 -0000

On Tue, Aug 30, 2022 at 02:11:57PM +0200, Bas Westerbaan wrote:
> For TLS on the Web it would be ideal if we can find a single[1] hybrid
> which we can all be happy with because that will make keyshare
> negotiation easier.

I don't suppose that will happen, as:

- Some folks want something with P384 classical part.
- Some folks do not want P384 classical part.
- Some folks do not want Kyber768, as it does not fit into MTU.

> The PQ hybrid situation is more painful. Suppose we end up with two
> essentially equivalent hybrids, say P-256+Kyber768 and
> X25519+Kyber768, and different servers have a different preference.
> Then clients are forced to either send both keyshares or suffer an
> HRR.

And without compression (which is not trivial to implement), sending
both uses quite a bit of space...
 
> Of course, we can change the server logic, but it isn't simple.

I think there could be some guidance on server logic.


And one another thing would be adding group hint to SVCB/HTTPS.
However, this would run into trouble with downgrade attacks.



-Ilari