On Thu, Oct 24, 2024 at 8:52 AM Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org> wrote: > > My personal feelings on pure vs composite are actually the union of several > previous comments: > > 1. Like EKR, I actually have a weak preference for composite, all other > things being equal. Failures happen and I like backup mechanisms > when they are relatively affordable and can be afforded. > 2. That said, I don't think composite should be forced on people. There are > valid use cases where I would recommend NOT using it, and I'm hearing > demand for both pure and composite. Like Scott said, I think we'll end > up standardizing both. > 3. Composite is slightly more complicated, though not as complicated as its > detractors claim. However, since composite signatures are not standardized > yet, I think they shouldn't be dragged into the 'pure' discussion. They > can have > their own draft and thread, like Diedre noted. > > I strongly oppose the "we have some time" sentiment, though. There are > ecosystems that are slow to transition due to long approval timelines and > the desire to do rigorous analysis and discussion, and some of them are > starting > to make transition plans now. The lack of IETF guidance on some of these > topics > is starting to be a blocker now that NIST algorithm specifications are > complete.
If there is an ecosystem that cannot afford an algorithm break in a signature, and where other constraints are less important, there is only one choice: hash based signatures. The difference in security between authentication and encryption (we do not need authentication to last more than a second beyond the lifetime of a connection) means that the consequences of a break are different. If tomorrow RSA was insecure, we would switch to ECC: no hybrid certs necessary. Likewise we can deploy multiple signature algorithms. Of course people complain that it takes time to switch certs etc. etc. That's exactly why we've invested in automated issuance. > > In the absence of standards, they will just do their own thing, and we'll end > up > with lots of unnecessary diversity and "interesting" design choices. > > -Tim > > > -----Original Message----- > > From: Alicja Kario <hka...@redhat.com> > > Sent: Thursday, October 24, 2024 5:57 AM > > To: Eric Rescorla <e...@rtfm.com> > > Cc: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; Bas > > Westerbaan <bas=40cloudflare....@dmarc.ietf.org>; <tls@ietf.org> > > <tls@ietf.org> > > Subject: [TLS] Re: ML-DSA in TLS > > > > On Thursday, 24 October 2024 04:47:02 CEST, Eric Rescorla wrote: > > > I think an adoption call is a bit premature here. We've got some time, > > > especially in the WebPKI setting. > > > > > > In particular, we should have a discussion of whether we want to > > > standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently > > > lean towards the latter, but I, at least, would like to hear arguments > > > to the contrary. > > > > For TLS I'm of the opinion that hybrids are not necessary. > > We might define hybrids later, if those gain traction, but pure have their > > place. > > > > > -Ekr > > > > > > > > > On Wed, Oct 23, 2024 at 11:02 AM John Mattsson > > > <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > > Let’s have an adoption call asap. > > > > > > > > > > > > I made some minor suggestions > > > https://github.com/bwesterb/tls-mldsa/pull/3 > > > > > > > > > > > > John > > > > > > > > > > > > From: Alicja Kario <hka...@redhat.com> > > > Date: Wednesday, 23 October 2024 at 19:59 > > > To: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> > > > Cc: <tls@ietf.org> > > > Subject: [TLS] Re: ML-DSA in TLS > > > > > > Hi, > > > > > > Thanks for the draft, will definitely be helpful. > > > > > > Few issues: > > > * The range 0x0900-0x0903 is reserved for backwards compatibility > > > I think it will be better to continue the numbering in the 0x08.. > > > space > > > * the must in "must use id_ML-DSA(...)" probably should be capitalised, > > > as > > > if it doesn't match, the connection needs to be aborted > > > > > > open question is if we should document error handling explicitly: > > > - illegal_parameter alert if the peer used algorithm not advertised, or > > > signature algorithm does not match the certificate > > > - decrypt_error when verification of the signature failed > > > > > > On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan 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: 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 -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
