Re: [COSE] [jose] ML-DSA & SLH-DSA for JOSE and COSE

Orie Steele <orie@transmute.industries> Sat, 13 January 2024 14:53 UTC

Return-Path: <orie@transmute.industries>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4B0C14EB17 for <cose@ietfa.amsl.com>; Sat, 13 Jan 2024 06:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
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 hrtrBrxNNPva for <cose@ietfa.amsl.com>; Sat, 13 Jan 2024 06:53:33 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0589C14F5FD for <cose@ietf.org>; Sat, 13 Jan 2024 06:53:33 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-5cf450eba00so1106904a12.0 for <cose@ietf.org>; Sat, 13 Jan 2024 06:53:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1705157613; x=1705762413; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JTei6WLg7uqfTAglqAcpICGy0jcCi7pJcFTQkf2SmuY=; b=K8pVGn8zVsoKtYHIOL7IpbVUSePDxRtH3HCwKYxttyClI1CC6aM55pYJiFvkg1maap DJcWONfVXj+XEpI8LlWRQk+ldhmH40Ul26+ZrPDlA4WFRQfixZ+ibUQj56JNCl6BnMgF gKQuAzkCscISe9x+7b0UhuKvrHpXbC0Gt7U9ELE9lLWyYXySnDwwtl+hrD2+nRzGmWVH m9O3jrsUzx7sCzU4RPSrzjNAj+4c9ivm6KqBtHxu/dF1mf49f0EzBImeCYny7j/qaCi4 N8XAwNPgFVXZrOgZOjjv72aX5EpgyKt0TQqr1cd+LoO6kLb/HmlaXiAjvXMI16d+iagT 6AdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705157613; x=1705762413; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JTei6WLg7uqfTAglqAcpICGy0jcCi7pJcFTQkf2SmuY=; b=BRtH6lNxHIdGa2Gj0Z2KX9d9PT7esG5aWdNO7Fgm05AEwl1v0V2kxYdMpYGsbImDcv rtb7UW9KV5BAqkwneVgttnd0AkWjFwXH0/HGW4IfLtYWgPWEzEWkTBKXxGNMJN9nkEbW Drx+JJcSDovsbjVxnRivr9xKHxOhrHueyMQ3X80a8TQ3bvRDFrX6gDtKi/A6bLd46Cym 4zb4GBKBNNPB7WxNiCF0Kdauq/CZuPnPHaACL0TWySTtgFWQQnyvw6/Oz5R3Lm3wS4LX NzLvJxSVi9Mt+UHnBlo9imLj+oSjONo2u1vX8DTlepOdN8SxknR5jJHvTFjFXYEm3FRR bHqg==
X-Gm-Message-State: AOJu0YwHlbhEiX46yWBqM7iMkn901AHaFpL4T4YrjmLuIyFjh81GKbiy K3yvNODh0kXXNE5Klo3tWk4TPFIUOX+cIk55Mn8H8AMy/knSJQ==
X-Google-Smtp-Source: AGHT+IG2huoUXSjOcuYGHZYeHBeOPF8DdEvrKL6Vh25VewnHkPpQjtFtY29qqBDqpTDWZ1K6NUzm7rXb/+XFevijArg=
X-Received: by 2002:a17:90b:115:b0:28c:e6c4:2af2 with SMTP id p21-20020a17090b011500b0028ce6c42af2mr2514647pjz.59.1705157613000; Sat, 13 Jan 2024 06:53:33 -0800 (PST)
MIME-Version: 1.0
References: <CAN8C-_K6SOv9s1MG9zw5sbc2sqq5AqJ9eX7av_QUW3-XzGZBQQ@mail.gmail.com> <1F043FBA-692F-4BD6-958B-1CFAE808E847@gmail.com>
In-Reply-To: <1F043FBA-692F-4BD6-958B-1CFAE808E847@gmail.com>
From: Orie Steele <orie@transmute.industries>
Date: Sat, 13 Jan 2024 08:53:22 -0600
Message-ID: <CAN8C-_J8fj6D6o3SY-BzxnX54pr2tr9QkMfj3oeyjis7LS5ang@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Cc: JOSE WG <jose@ietf.org>, cose <cose@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cf2b1a060ed4f10b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/AGrnyoNKM1ONc2MhxOWm5tMaJq8>
Subject: Re: [COSE] [jose] ML-DSA & SLH-DSA for JOSE and COSE
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jan 2024 14:53:37 -0000

Hey Neil : )

On Sat, Jan 13, 2024 at 8:33 AM Neil Madden <neil.e.madden@gmail.com> wrote:

> I’m still catching up with JOSE activity from the last year or so, so
> apologies if this has already been discussed.
>
> If I’m reading the specs right, the smallest signature for ML-DSA is
> almost 2.5KB on its own — about 10x the size of RSA-2048, which is already
> pushing it, size-wise, for many applications. Compared to Ed25519 we’re
> looking at an almost 40-fold increase in size. For SPHINCS+ the smallest
> appears to be about 8KB — ie on its own it is double the maximum total size
> for cookie storage in a web browser, and that’s before base64-encoding.
>
> Given that the quantum threat for signatures is less pressing than it is
> for encryption (where you need to worry about collection happening now),
> maybe it might be worth waiting to see if the ongoing NIST process throws
> up some candidates that might be more suitable in a JOSE/COSE scenario? (I
> only have limited experience with COSE, but surely if anything these
> concerns are even more acute in that case?)
>

Here is a blog post summarizing the NIST candidates:
https://blog.cloudflare.com/nist-post-quantum-surprise

Falcon was the smallest, but seems to have not been chosen:

"Unfortunately, NIST stated on several occasions that it would choose only
two signature schemes, but not both Falcon and Dilithium"

This is the reason we (cose wg draft authors) have not revised the falcon
draft which was adopted by the cose wg.

I agree with your comments, but given the trends we see in LAMPS / TLS, I
feel it's important that when post quantum signatures roll out elsewhere,
JOSE and COSE have support for them to the same degree that other protocols
do.

In case you are more interested in post quantum alignment, I highly
recommend:

https://datatracker.ietf.org/wg/pquip/about/

In particular, since we have just discussed signatures, keys and params, I
was planning to follow the advice we got regarding limiting registrations
for SLH-DSA in JOSE and COSE:

- https://mailarchive.ietf.org/arch/msg/pqc/bi3fNCDk4upbxnxeVNLUp-5EgEE/

We could even limit further from 12 to 8 to 6 perhaps (3 levels, and 2 hash
functions).

Regards,

OS




>
> — Neil
>
> On 12 Jan 2024, at 22:03, Orie Steele <orie@transmute.industries> wrote:
>
> 
> Hello Post Quantum Enthusiasts,
>
> We apologize for allowing the drafts to expire, that has now been
> corrected.
>
> We've published new versions and done a tooling migration to the COSE WG
> GitHub repository:
>
> - https://github.com/cose-wg/draft-ietf-cose-dilithium
> - https://github.com/cose-wg/draft-ietf-cose-sphincs-plus
>
> Here is a quick summary of what changed, but of course you can see the
> full diff in the datatracker.
>
> 1. We adjusted the names to reflect FIPS.204 (IPD) and FIPS.205 (IPD)
> 2. We removed extraneous text on the details of the algorithms, which is
> better covered in the references noted above.
> 3. We provided skeletons for examples
>
> We are seeking implementations of ML-DSA and SLH-DSA in order to update
> the examples sections, with closer to real world data.
>
> We have opted not to migrate Falcon, the parameter sets for sphincs will
> probably keep us busy for a while.
>
> I'd like to take this opportunity to complain a bit about this part of the
> FIPS 205 IPD:
>
> " This standard approves 12 parameter sets for use with SLH-DSA. "
>
> I feel this is a mistake, and wonder if there is any opportunity to reduce
> this to something less than 4x the number defined by ML-DSA.
>
> Even if NIST preserves all 12, we don't have to register all 12 in
> draft-ietf-cose-sphincs-plus.
>
> ... I really don't want to have to generate 12 key pairs and signature
> examples, especially because a single key pair with the required line
> breaks is likely to be longer than the entire draft.
>
> Of course, we will do whatever the working group thinks is correct here...
> what should we do?
>
> Regards,
>
> OS
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>