On Wed, Mar 13, 2024 at 4:10 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote:
> Also, what are the WG's thoughts on including standalone PQC signatures in > the same draft? > > > > I think that including standalone PQC sigs would be very desirable. > > > > I don't think there is any particular reason to include PQC signatures in > the same draft as PQ key establishment. In TLS 1.3, key establishment and > signature are orthogonal concepts, and it will be easier to review if they > are kept in separate documents. > > > > On the one hand – you’re correct. On the other hand, though, considering > implicitly-authenticated protocols, such as MQV, HMQV etc…? > *Yes I’m aware that they don’t use explicit signatures, except to validate > certificates.* > TLS 1.3 does not support MQV or HMQV. -Ekr > > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of *Deirdre Connolly > *Sent:* Tuesday, March 5, 2024 9:15 PM > *To:* TLS@ietf.org > *Subject:* [TLS] ML-KEM key agreement for TLS 1.3 > > > > I have uploaded a preliminary version of ML-KEM for TLS 1.3 > <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> > and have a more fleshed out > <https://github.com/dconnolly/draft-tls-mlkem-key-agreement> version to > be uploaded when datatracker opens. It is a straightforward new > `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a > very similar style to -hybrid-design > <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>. > > > > It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0 > compatible) ready to go when users are ready to use them. > > > > Cheers, > > Deirdre > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
