IETF Logo Mail Archive

Re: [TLS] [UNVERIFIED SENDER] Re: Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 12 May 2023 06:19 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 B2015C152567 for <tls@ietfa.amsl.com>; Thu, 11 May 2023 23:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 nAqDGpTbdM7e for <tls@ietfa.amsl.com>; Thu, 11 May 2023 23:19:27 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3b.welho.com [83.102.41.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83ED5C1524DD for <tls@ietf.org>; Thu, 11 May 2023 23:19:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 6CB3B19C7C for <tls@ietf.org>; Fri, 12 May 2023 09:19:23 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Lfha9c3B--bd for <tls@ietf.org>; Fri, 12 May 2023 09:19:23 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-94-129-82.rev.dnainternet.fi [87.94.129.82]) (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 320DF2309 for <tls@ietf.org>; Fri, 12 May 2023 09:19:22 +0300 (EEST)
Date: Fri, 12 May 2023 09:19:21 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <ZF3aaa7YB16X/mGZ@LK-Perkele-VII2.locald>
References: <FBE87FDA-A407-4DC8-A2E8-F39AB475C87B@heapingbits.net> <C446C65E-924F-4927-BF53-E0B13EFC4930@heapingbits.net> <CAMjbhoXYiX2AP9w6JvCRuhPSvuEEWjBbLJhwVAKZhOByOnfeXw@mail.gmail.com> <920f6d11f8994141a9fba472236e2988@amazon.com> <CAMjbhoXGHHym+og+ORkJ8LnUiD+j+bBp4Xub+Ojv8GpTTpyzag@mail.gmail.com> <20522fd9a6cc40f1be6854e0b037e9a8@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20522fd9a6cc40f1be6854e0b037e9a8@amazon.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XHJAucUUMAPqpEHqBl7mKyjJD8M>
Subject: Re: [TLS] [UNVERIFIED SENDER] Re: Consensus call on codepoint strategy 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: Fri, 12 May 2023 06:19:28 -0000

On Thu, May 11, 2023 at 02:44:18PM +0000, Kampanakis, Panos wrote:
> ACK, thx all. So we should refrain from defining such “point-in-time”
> codepoints for other needed long-term algorithm combinations to not
> waste registry space. Only absolutely necessary codepoints should be
> registered.

That registry has >64,000 free codepoints. I don't see there being
anywhere close enough individual registrations to fill that up, no
matter how loose the criteria are.

However, with post-quantum, there is another reason to be careful:
The shares are so large that the client effecively only has one shot.


Some sort of systematic registrations reseving large chunks of space
is the only way I can foresee the registry being seriously depleted.
In contect of TLS groups, No such registrations exist currently, nor
have I seen proposals for such thing.




-Ilari

v2.23.0 | Report a Bug | By Email