Should x25519 be made MTI?

[sftcd]

It seems pretty ubiquitous both in terms of implementation and deployment and if some client are emitting only x25519 shares in ClientHello, then making it MTI might improve interop, so... should we?

[loganaden]

I believe that that x25519 should be MTI.

[tomato42]

:-1: from me, not because x25519 is bad (it's good), but because it as MTI will be pretty meaningless: P-256 is the curve for interop, and will remain so, the next big thing will be ML-KEM, not migration to x25519...

[sftcd]

FWIW, I don't think making x25519 MTI would be a next big thing or anywhere near; more a recognition of reality in order to encourage anyone who hasn't included it in their implementation to move towards doing so

[richsalz]

P-256 is the curve for interop,

For key exchange? Strongly disagree. In our experience P256 is used when needed for compliance. Our customers prefer X25519 for speed.

[emanjon]

I think x25519 should be MTI. But I don't think this helps with interop. I think the problem is servers not supporting HRR. I think HRR should be MTI.

[tomato42]

P-256 is the curve for interop,

For key exchange? Strongly disagree. In our experience P256 is used when needed for compliance. Our customers prefer X25519 for speed.

I meant it as "a fallback that basically everybody supports"

I think HRR should be MTI.

HRR already is MTI

[emanjon]

I think HRR should be MTI.

HRR already is MTI

In that case, maybe it should be clarified that HRR is mandatory. My understanding of this discussions is that IoT servers which do not support cannot interop with Chrome. The suggestion on the list was that this is Chrome's fault. I agree that it is the servers fault.

[Andrei-Popov]

I am opposed to making 25519 MTI for a couple of reasons:

1. A lot of environments are limited to NIST curves by regulation, so they cannot be compliant with any RFC that requires X25519 support.
2. Changes to MTI algorithms don't sound appropriate in a -bis document: this change would break interoperability with rfc8446-compliant implementations.

[sftcd]

2. Changes to MTI algorithms don't sound appropriate in a -bis document: this change would break interoperability with rfc8446-compliant implementations.

I don't understand how adding an MTI would do that.

[richsalz]

I meant it as "a fallback that basically everybody supports"

That I fully agree with.

[russhousley]

2. Changes to MTI algorithms don't sound appropriate in a -bis document: this change would break interoperability with rfc8446-compliant implementations.

A rfc8446-compliant implementation will not be able to interoperate with a rfc8446bis-compliant implementation with X22619. I'd rather not create a situation like this when we are facing many algorithm transition issues in the next few years,

[ekr]

A rfc8446-compliant implementation will not be able to interoperate with a rfc8446bis-compliant implementation with X22619. I'd rather not create a situation like this when we are facing many algorithm transition issues in the next few years,

I don't know what I think about this proposal, but I'm not sure this is correct. As I understand it, the proposal is:

RFC 8446: MUST P-256 RFC 8446-bis: MUST P-256, MUST X25519

If each implementation only supports the MTIs, then you get the following interop matrix for which algorithm is used:

                  8446     8446-bis
8446             P-256        P-256
8446-bis         P-256       either

It's true that 8446 implementations will not be compliant with 8446-bis, but I don't see how that creates an interop issue. What am I missing?

[russhousley]

@ekr. Correct. I was trying to address the point that was raised by @Andrei-Popov. That is, the interoperability will only exist with X25519.

[emanjon]

I am not sure that this change is needed either, but making X25519 MTI seems preferred to forcing P-256 key shares in CH.

Andrei Popov wrote:

A lot of environments are limited to NIST curves by regulation I don't think national regulation has or should have an impact on IETF MTI algorithms. The strength with IETF is that IETF does not follow any specific national regulation. It is impossible to follow all national regulations. That IETF uses a lot of of NIST algorithms is not because IETF has to, but because NIST algorithms typically are very good and selected in open projects with leading cryptographers from around the world.

[kaduk]

I am opposed to making 25519 MTI for a couple of reasons:

1. A lot of environments are limited to NIST curves by regulation, so they cannot be compliant with any RFC that requires X25519 support.

As I note in https://github.com/tlswg/tls13-spec/issues/1358#issuecomment-2150482377 an "application profile standard" can supersede the base spec's MTI, and we have seen NSA come in and write application profile specifications for, e.g., Suite B and CNSA, so I'm not convinced that "my regulated environment requires NIST curves" is a fatal flaw; it can be mitigated by pointing to a profile spec that records the requirements for that (class of) environment.

2. Changes to MTI algorithms don't sound appropriate in a -bis document: this change would break interoperability with rfc8446-compliant implementations.

I also don't understand this argument; are you saying that the MTI algorithms will be fixed for TLS 1.3 for all time? If not, how else other than a -bis would they change? I think we have counterexamples like RFC 9142 that specifically change the MTI algorithms for in-use protocols over time.

[legna37]

envvars_backend.txt

[ekr]

Closing per WG consensus.