Mike Ounsworth <[email protected]> writes: > My position is that the IETF is a technical standards body, not a policy > body. Documenting security concerns in the Security Considerations is > fine,
Why has that been rejected, though? The "Security Considerations" could say people should prefer hybrids for risk-minimization and that lattices is a young research field and that we are early in deployment of it. It doesn't, and saying that has been rejected, and the WG Chairs haven't insisted on proper security considerations. Saying that in the WGLC announcement, but not in the document itself, and infering some semantic value for the RECOMMENDED field seems wrong to me. This means the document face value will be usable to promote something that the WG believe is weaker. That's not what we should do in the IETF. The third WGLC announcement message is not a useful reference for a more complete ML-KEM Security Considerations. > but outright blocking the publication of a technically mature, > deployable, and desired document seems to me to be straying outside of > technical work into political and policy work. Publishing ML-KEM via the TLS WG on the Standards Track is part of political and policy work. > Moreover, given expected migration lead times for some large organizations, > it seems to me that getting any kind of PQC into deployment pipelines soon > is more important than exactly which PQC that is. Delaying publication will > itself cause more harm than publishing something sub-optimal. Let's publish > the things that people clearly want to use. We don't have to publish it through the TLS WG though, which normally is a gatekeeper for what people want to use AND what experts believe is safe. Brainpool curves and ShangMi ciphers for TLS were published as ISE submissions, and this seems like an appropriate venue for something like non-hybrid ML-KEM too. /Simon > -Mike Ounsworth > > On Wed, Jul 1, 2026, 14:52 Sophie Schmieg <sschmieg= > [email protected]> wrote: > >> As I mentioned in my blog post [1], MTI is a joke, invented to create more >> discussion in IETF mailing lists. There is no RFC police, and nobody can >> force anyone to implement an algorithm (other than, as David Benjamin >> noted, the null algorithm as that is the state of the uninitialized TLS >> stack). The flag you are looking for is the IANA recommended flag. And >> hybrids are recommended, pure ML-KEM is not. >> >> In general, the question here is not whether or not hybrid key exchange >> algorithms should be used or even should be used as default, it is whether >> anybody is allowed to not use a hybrid in a standardized fashion, if both >> sides of the connection agree to do so. (Insert meme: I consent/I consent/I >> don't). >> >> Hybrid key exchanges are recommended by the IETF, all browsers are >> implementing them by default, all server stacks that I'm aware of implement >> them by default. Meanwhile pure ML-KEM is afaik only implemented behind >> flags, in any browser or server stack I know of. Objecting this draft on >> the basis that hybrid is more secure and should be the default choice shows >> lack of understanding of the situation, likely caused by certain >> technically correct, but highly misleading statements one might have >> encountered on social media. >> >> [1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ >> >> On Wed, Jul 1, 2026 at 2:22 PM Justin Schnurbusch <schnurbusch.justin= >> [email protected]> wrote: >> >>> Yes, you got that correct. >>> >>> The thing is that it seems to me (absolutely subjective) that there needs >>> to be a definitely secure baseline due to the nature of humans. >>> >>> Especially due to the fact that the hybrid implementations are slightly >>> less performant - some might take this as an argument to say "We don't do >>> hybrid here, look at the performance!" We all around this list know that >>> these performance differences are absolutely negligible - but that may be >>> not case everywhere. >>> >>> And, regarding the fact that the intended status of this draft is >>> informational, in combination with a MTI hybrid and a currently secure >>> baseline, I would support the publication of this draft. >>> >>> Kind regards >>> Justin >>> >>> >>> Am 30. Juni 2026 19:53:48 MESZ schrieb Eric Rescorla <[email protected]>: >>> >>>> >>>> >>>> On Tue, Jun 30, 2026 at 10:49 AM Justin Schnurbusch <schnurbusch.justin= >>>> [email protected]> wrote: >>>> >>>>> I do not support the publication of this document as it seems to me >>>>> that the implementations "in the field" need a currently secure baseline >>>>> as >>>>> a mandatory border. >>>>> >>>>> A more baseline-mandatory approach with an optional component seems >>>>> more reasonable to me. >>>>> >>>> >>>> I'd like to make sure I understand your position: Are you saying that if >>>> some hybrid (e.g., X25519-MLKEM) were MTI, you would support this draft? >>>> >>>> -Ekr >>>> >>>> _______________________________________________ >>> TLS mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> >> -- >> >> Sophie Schmieg | Information Security Engineer | ISE Crypto | >> [email protected] >> >> _______________________________________________ >> 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] >
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
