On Fri, Nov 15, 2024 at 5:18 PM John Mattsson <john.matts...@ericsson.com> 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 <rmguthr=40uwe.nsa....@dmarc.ietf.org> > *Date: *Friday, 15 November 2024 at 17:09 > *To: *<tls@ietf.org>, Bas Westerbaan <b...@cloudflare.com> > *Cc: *John Mattsson <john.matts...@ericsson.com>, Alicja Kario < > hka...@redhat.com> > *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 <john.mattsson=40ericsson....@dmarc.ietf.org> > *Sent:* Friday, November 15, 2024 9:41 AM > *To:* Alicja Kario <hka...@redhat.com>; Bas Westerbaan <bas= > 40cloudflare....@dmarc.ietf.org> > *Cc:* <tls@ietf.org> <tls@ietf.org> > *Subject:* [TLS] Re: ML-DSA in TLS > > > > > Very happy to see it. > > > >I'm for workgroup adoption of it. > > > > +1 > > > > *From: *Alicja Kario <hka...@redhat.com> > *Date: *Friday, 15 November 2024 at 15:34 > *To: *Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> > *Cc: *<tls@ietf.org> > *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 <b...@cloudflare.com> > 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 -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
