On Fri, Nov 15, 2024 at 5:18 PM John Mattsson <[email protected]> wrote:
> Agree with Rebecca's comments on ML-DSA and HashML-DSA. After discussing > ML-DSA a lot with developers, I have noticed that after being used with > RSA and ECDSA where they needed to combine RSA and ECDSA with a hash > function, they have a hard time to understand that ML-DSA does not need an > additional hash function. I think it would be good to explain this for many > readers. > Good point. We can add some words to that affect in LAMP's dilithium-certificates. For this TLS document it feels a bit out of place. > > John > > > > *From: *Rebecca Guthrie <[email protected]> > *Date: *Friday, 15 November 2024 at 17:09 > *To: *<[email protected]>, Bas Westerbaan <[email protected]> > *Cc: *John Mattsson <[email protected]>, Alicja Kario < > [email protected]> > *Subject: *RE: [TLS] Re: ML-DSA in TLS > > I also support WG adoption. > > > > One suggestion in the Introduction: > > > > "ML-DSA [FIPS204] is a post-quantum signature schemes standardised by > NIST. It is a module-lattice based scheme." -> "ML-DSA is a > module-lattice-based digital signature algorithm standardised by NIST in > [FIPS204]." > > > > And one suggestion in Section 3: > > > > "Note that these are the pure versions and should not be confused with > prehash variants such as HashML-DSA-44 also defined in [FIPS204]." -> "Note > that these values represent ML-DSA and not HashML-DSA [FIPS204, Section > 5.4]." > > > > Those who read this later who have not been following mailing list > discussions might not understand what is meant by "pure versions" since the > word "pure" is not used in FIPS 204- so it is probably best to just call > these ML-DSA and HashML-DSA. It may also be helpful to include a pointer to > the specific section in FIPS 204 where HashML-DSA is defined. > > > > Rebecca Guthrie > > she/her > > Center for Cybersecurity Standards (CCSS) > > Cybersecurity Collaboration Center (CCC) > > National Security Agency (NSA) > > > > *From:* John Mattsson <[email protected]> > *Sent:* Friday, November 15, 2024 9:41 AM > *To:* Alicja Kario <[email protected]>; Bas Westerbaan <bas= > [email protected]> > *Cc:* <[email protected]> <[email protected]> > *Subject:* [TLS] Re: ML-DSA in TLS > > > > > Very happy to see it. > > > >I'm for workgroup adoption of it. > > > > +1 > > > > *From: *Alicja Kario <[email protected]> > *Date: *Friday, 15 November 2024 at 15:34 > *To: *Bas Westerbaan <[email protected]> > *Cc: *<[email protected]> > *Subject: *[TLS] Re: ML-DSA in TLS > > Very happy to see it. > > I'm for workgroup adoption of it. > > On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote: > > We have posted a -00. > > > > https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00 > > > > > > > > On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan <[email protected]> > wrote: > > Hi all, > > > > Unless I overlooked something, we don't have a draft out to > > assign a SignatureAlgorithm to ML-DSA for use in TLS. > > > > It's two days past the I-D submission deadline, but I wanted to > > point you to a short draft we put together to fill this gap. > > > > https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html > > > > So far, I see only one open question: whether to set a non-zero > > context string. > > > > Best, > > > > Bas > > > > > > > > -- > Regards, > Alicja (nee Hubert) Kario > Principal Quality Engineer, RHEL Crypto team > Web: https://www.redhat.com/en/global/czech-republic?oh=www.cz.redhat.com > <http://www.cz.redhat.com/> > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
