[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 03 November 2024 08:41 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 52F93C151992 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2024 01:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 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, 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 TY7Bq-N_9E5X for <tls@ietfa.amsl.com>; Sun, 3 Nov 2024 01:41:54 -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 61999C15154F for <tls@ietf.org>; Sun, 3 Nov 2024 01:41:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DB5F7151F0 for <tls@ietf.org>; Sun, 3 Nov 2024 10:41:50 +0200 (EET)
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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 0UmLd_pYjl1k for <tls@ietf.org>; Sun, 3 Nov 2024 10:41:50 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-153-79.rev.dnainternet.fi [87.92.153.79]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 825F128B for <tls@ietf.org>; Sun, 3 Nov 2024 10:41:49 +0200 (EET)
Date: Sun, 03 Nov 2024 10:41:49 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <Zyc3TQoGtAD345b3@LK-Perkele-VII2.locald>
References: <173059220278.350115.6583095374531712492@dt-datatracker-84cf84bdcc-hlxgg> <CAFpG3gcVZ184JX3FWjQo5CUi+MEnrNK7MWVB+iz7wMwp7oYrXg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFpG3gcVZ184JX3FWjQo5CUi+MEnrNK7MWVB+iz7wMwp7oYrXg@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: 6DLKT73ACMTL24TYF4BCI5ZTLHWBUNQ7
X-Message-ID-Hash: 6DLKT73ACMTL24TYF4BCI5ZTLHWBUNQ7
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.9rc6
Precedence: list
Subject: [TLS] Re: Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt
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/mrnfCEVT1gAXAS1YDDRZV7xjlNY>
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 Sun, Nov 03, 2024 at 05:37:34AM +0530, tirumal reddy wrote:
> 
> The draft https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> specifies how ML-DSA in combination with traditional algorithms can be used
> for authentication in TLS 1.3.
> 

Important details, such as how signature are encoded seems to be
missing.


And I think this is very premature. As far as I can tell, there are
major unaddressed issues with hybrid signatures. Those issues need to
be settled first before adding any codepoints.

Having multiple variants of the same hybrid signature is not acceptable
due to severe security risks from overloading crypto library authors.

Furthermore, the encodings used by draft-ietf-lamps-pq-composite-sigs
add additional security risks. Modern crypto design uses byte string
I/O for safety.


Currently, only bare ML-DSA and SLH-DSA are usable for post-quantum
signature authentication. Seems that the only question that does not
have an obvious answer is the context to use.




-Ilari