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

On Sat, 2024-01-13 at 08:53 -0600, Orie Steele wrote:
> 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"

It is not clear to me why you read second hand opinions instead of
looking at the official statements, but Falcon has been, in fact,
selected.

NIST has announced 4 QR algorithms, 1 for encryption:
- CRYSTALS-Kyber
And 3 for signatures:
- CRYSTALS-Dilithium,
- Falcon
- SPHINCS+

Official Announcement:
https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms

Page with the list of selected algorithms:
https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022

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

This is quite surprising to be honest, the selection was 1.5 years ago.

> 
> 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).
> 

I would honestly wait for registration until the Standards are released
because NIST is still tweaking some of the parameters.

There is also the possibility, as it happened before with SHA-3 and
AES, that NIST will rename the algorithms on the final official
standard, and it is messy and confusing to use different names in
standards (nobody uses Keccak or Rjiandel in standards, they all refer
to SHA-3 and AES).

HTH,
Simo.

> 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
> > 
> > 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc