I fully agree. I believe that MTI should be the lowest common denominator - something that is not necessarily the best current practice from compute efficiency or security perspectives but something that is most widely supported and is good enough for most use cases. MTI is supposed to be reasonably long-term stable within a given protocol version and change only when it is no longer fit for purpose - for example, not considered to be cryptographically strong enough or overwhelmingly computationally inefficient compared to an alternative approach.
While for most use cases x25519 seem to be superior to secp256r1, I don't think the difference is big enough to risk potential disruption caused by incompatibility between 8446 and 8446-bis. On top of that it is perfectly possible that in some not-so-distant future a hybrid KEM or a pure post-quantum KEM will be considered a minimally cryptographically acceptable approach and MTI will need to be updated yet again. Current situation that x25519 is so strongly preferred by most TLS clients that they include only it (and maybe x25519Kyber768Draft00) in the initial ClientHello key_share and require HRR for servers and proxies that really don't want to use it is clearly suboptimal. But I personally believe that instead of changing MTI, acceleration of standardisation and adoption of draft-ietf-tls-key-share-prediction is a more versatile and future-proof way to improve KEM negotiation while reducing risks of additional connection delays caused by HRR. Best Regards, Yaroslav On Wed, Jul 10, 2024 at 11:40 PM Salz, Rich <rsalz= 40akamai....@dmarc.ietf.org> wrote: > I read through the discussion pointed-to by the PR. > > > > I’m a little uncomfortable of putting this into the 8446bis document > because as I understand it, this is really “just” a cleanup release fixing > terminology, closing errata, etc. Significant changes shouldn’t be there. > On the bright side, however, I don’t think it matters much since browsers > will always want to try X25519 because of the performance; it’s not going > away. > > > _______________________________________________ > 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
