I support adoption. I agree with John that reuse of ephemeral keys is a far bigger security problem, in theory and even more so in practice.
Coincidentally, I disagree with Stephen – there’s no need to encourage or discourage either hybrids or pure KEMs. -- V/R, Uri From: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Date: Tuesday, April 1, 2025 at 10:47 To: Stephen Farrell <stephen.farr...@cs.tcd.ie>, IETF Secretariat <ietf-secretariat-re...@ietf.org>, draft-connolly-tls-mlkem-key-agreem...@ietf.org <draft-connolly-tls-mlkem-key-agreem...@ietf.org>, tls-cha...@ietf.org <tls-cha...@ietf.org>, tls@ietf.org <tls@ietf.org> Subject: [EXT] [TLS] Re: The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state "Call For Adoption By WG Issued" >I think we ought to encourage hybrids >I think following the old practice of >telling the ISE we have no objection to this ending up as an independent >stream RFC is the better approach for this one I think reuse of ephemeral keys >is a ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory. ZjQcmQRYFpfptBannerEnd >I think we ought to encourage hybrids >I think following the old practice of telling the ISE we have no objection to >this ending up as an independent stream RFC is the better approach for this one I think reuse of ephemeral keys is a much bigger practical security problem than not using hybrids. I do have objections to ISE publishing anything allowing reuse of ML-KEM encapsulation keys. John From: Stephen Farrell <stephen.farr...@cs.tcd.ie> Date: Tuesday, 1 April 2025 at 16:30 To: IETF Secretariat <ietf-secretariat-re...@ietf.org>, draft-connolly-tls-mlkem-key-agreem...@ietf.org <draft-connolly-tls-mlkem-key-agreem...@ietf.org>, tls-cha...@ietf.org <tls-cha...@ietf.org>, tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state "Call For Adoption By WG Issued" Hiya, I'm opposed to adoption, at this time. - I think we ought to encourage hybrids but not pure PQ KEMs and so adopting documents on hybrid KEMs can make sense so we can more easily get to a reommended="Y" in the IANA registry when the WG wants to - I don't see what criteria we might use in adopting this that wouldn't leave the WG open to accusations of favouritism if we don't adopt other pure PQ national standards that will certainly arise For the above reasons, I think following the old practice of telling the ISE we have no objection to this ending up as an independent stream RFC is the better approach for this one, and similar ones. If/as confidence in pure-PQ KEMs grows or a CRQC is closer to being demonstrated we could revisit things then. I do understand that some people will want/need to use this, but figure an ISE RFC is better in this case. Cheers, S. On 01/04/2025 13:58, IETF Secretariat wrote: > > The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state > Call For Adoption By WG Issued (entered by Sean Turner) > > The document is available at > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-connolly-tls-mlkem-key-agreement%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C9d70cccdc0534f8976fb08dd7129c34e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638791146385734829%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ffr1LYVHRNuy%2BxRWxiD9L0WAKs%2BmrzgBkon6fBrkfmg%3D&reserved=0<https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> > > > _______________________________________________ > 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
