Require sending MTI curves in CH.key_share

[ekr]

Peter Gutmann suggests requiring that the CH require an MTI curve in CH.key_share:

Eric Rescorla [ekr@rtfm.com](mailto:ekr@rtfm.com) writes:

One more thing: we are finalizing RFC 8446-bis right now, so if there is WG consensus to require that clients offer all MTI curves in the key_shares of their initial CH, then that would be a straightforward text change.

That would fix things, something like saying a client has to provide at least one MTI cipher suite/signature/keyex in its client hello. There's only one MTI curve in 8446 so "all MTI curves" isn't a big deal.

[sftcd]

Would if be on/off topic here to suggest adding x25519 as another MTI at the same time?

[ekr]

Off-topic for this issue, I think. Please file another if you want to discuss that.

[ekr]

FWIW, I don't think we should make the change that is proposed here.

[sftcd]

I opened #1359

[ekr]

I opened #1359

Thank you.

[davidben]

I'm strongly opposed. If it is in the spec, we will ignore it.

There are many reasons a client may not want to send an MTI curve in the initial key share, e.g. if it has prior knowledge of the server's preferences or if it does not want to waste CPU cycles on a curve that most servers won't pick. The TLSWG also has a poor track record with MTI options. I recall a weird "must implement but need not enable" reverse justification for the TLS 1.2 and earlier MTIs.

Indeed we already know we will be doing a PQ transition in the future, and eventually all the current MTIs will need to be removed. Adding rules to prevent their removal just further dilutes the TLSWG's notion of MTI.

(One could argue that notion is already meaningless, in which case I suppose this change is fine and only further serves to make this obvious.)

[bwesterb]

I agree with @davidben

[tomato42]

fully agree with @davidben

[emanjon]

agree with @davidben

[dennisjackson]

Agree with @davidben

[Andrei-Popov]

I support this change, willing to implement it in the Windows TLS stack. We have thousands of customers concerned about increased latencies due to the enablement of TLS 1.3. The services they connect to require NIST curves and HRR is required to get Web browsers to send appropriate key shares. TLS 1.3 with HRR is somewhat higher-latency than TLS 1.2 full handshake.

(Of course, TLS key share prediction could override this, when the server's DNS record indicates no P256 support. The key share prediction draft can include this provision.)

[kaduk]

Yeah, @davidben has a good summary. The key part is that historically our position on MTI is mandatory to implement but not mandatory to use/enable; by requiring the client to send a key share we are promoting MTI to a requirement to use, at least for the client. But absent an analogous requirement on the server, just sending the MTI key share does not guarantee a successful connection, let alone a successful connection without HRR. A server might still not want to use the MTI algorithm in question (and the issue is compounded greatly if we go to a scenario where we have more than one MTI keyex algorithm).

I think if we look at a broad IETF-wide perspective on how MTI is treated, I think it is generally biased towards the "implement but not necessarily use" mindset that TLS has taken in the past. I also think there were some scenarios with, e.g., IPSec that did in effect have mandatory-to-use algorithms and that had negative security consequences for the ecosystem, by providing inertia to stick with algorithms that grew weak. In some ways it's worse for ssh, which was slow to update the recommendations (demoting the weaker algorithms and promoting new ones -- RFC 9142 only came out in 2022, and diffie-hellman-group1-sha1 is only "SHOULD NOT" rather than "MUST NOT", because the previous recommendation was "MUST").

I don't think we get much tangible interoperability benefit from this, and the cost is a significant hampering of the ability of willing endpoints to exercise algorithm agility and move away from using algorithms that clients do not wish to support.

[kaduk]

I support this change, willing to implement it in the Windows TLS stack. We have thousands of customers concerned about increased latencies due to the enablement of TLS 1.3. The services they connect to require NIST curves and HRR is required to get Web browsers to send appropriate key shares. TLS 1.3 with HRR is somewhat higher-latency than TLS 1.2 full handshake.

I don't think requiring every client implementation to use a specific algorithm is a good way to reduce latency. If a set of endpoints wants to ensure a lower latency, they have the ability to agree out of band on what algorithms to prefer, including but not limited to by having the server advertise its configuration/preferences in a DNS record.

[Andrei-Popov]

The key part is that historically our position on MTI is mandatory to implement but not mandatory to use/enable; by requiring the client to send a key share we are promoting MTI to a requirement to use, at least for the client.

The client would only be sending a P256 key share when P256 support is advertised, i.e. P256 is not disabled. I don't believe this is a requirement to use: the client can also send other key shares and the server can still negotiate a different group.

If a set of endpoints wants to ensure a lower latency, they have the ability to agree out of band on what algorithms to prefer, including but not limited to by having the server advertise its configuration/preferences in a DNS record.

Agreed, and explicitly pointed out this case in my very first comment above.

[ekr]

@kaduk I would note that the text here actually says that "TLS-compliant application MUST support key exchange with secp256r1". I generally interpret this as not just MUST implement but rather MUST enable.

I agree that this does not require sending anything in particular in CH.key_shares

[kaduk]

Oh hmm, the recent replies make it sound like we do not actually agree on what we are discussing.

Andrei's

The client would only be sending a P256 key share when P256 support is advertised, i.e. P256 is not disabled. I don't believe this is a requirement to use: the client can also send other key shares and the server can still negotiate a different group.

sounds like he believes that the proposed change here is to require sending a P256 key share when that group is in supported_groups, which is not what I interpret the proposal quoted in the initial comment as saying. (I read that quoted proposal as saying that literally every CH.key_share needs to include P256.)

ekr's reply to me suggests that there is a separate requirement for every CH.supported_groups to include P256, in which case Andrei's interpretation collapses down to be in practice the same as my interpretation. But I don't agree with ekr in this regard :)

For a little more context, the entirety of section 9.1 (mandatory-to-implement cipher suites) of RFC 8446 is:

In the absence of an application profile standard specifying
   otherwise:

   A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
   [[GCM](https://www.rfc-editor.org/rfc/rfc8446.html#ref-GCM)] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
   [[GCM](https://www.rfc-editor.org/rfc/rfc8446.html#ref-GCM)] and TLS_CHACHA20_POLY1305_SHA256 [[RFC8439](https://www.rfc-editor.org/rfc/rfc8439)] cipher suites (see
   [Appendix B.4](https://www.rfc-editor.org/rfc/rfc8446.html#appendix-B.4)).

   A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [[RFC7748](https://www.rfc-editor.org/rfc/rfc7748)].

Yes, there is an interesting difference in word choice between paragraphs ("implement" vs "support"). But I don't think that we say anything about "support" being "at runtime" vs "in the codebase", and my recollection is that at the time we wrote that we did not mean that it must be enabled at runtime. And, as the very first quoted sentence says, an application profile standard can overrule all of this, so it's clearly not the case that we intended this to be absolutely hardcoded into implementations without any configuration option at all.

So I'd like to get a better sense of (1) whether we all agree on what is actually being proposed, and (2) what the current requirement from RFC 8446 is.

[bwesterb]

@Andrei-Popov wrote

I support this change, willing to implement it in the Windows TLS stack. We have thousands of customers concerned about increased latencies due to the enablement of TLS 1.3.

You can implement this today. What puzzles me is that you mention increased latency: TLS 1.2 should be very similar in performance to TLS 1.3 where the client doesn't send any keyshare at all.

[dvorak42]

If the consensus ends up being not to requiring the MTI curves, I wonder if it would be useful to add some text to clarify that having CH.key_share sent without including the MTI key shares is compliant behavior.

[Andrei-Popov]

You can implement this today. What puzzles me is that you mention increased latency: TLS 1.2 should be very similar in performance to TLS 1.3 where the client doesn't send any keyshare at all.

I can implement this today, but it won't help much: I don't control popular Web browsers.

What puzzles me is that you mention increased latency: TLS 1.2 should be very similar in performance to TLS 1.3 where the client doesn't send any keyshare at all.

I thought it should be as well, until we actually measured, using a couple different popular TLS stacks.

[davidben]

Browsers typically implemented False Start with TLS 1.2 (under various conditions, some security and some compat), so that's probably why the difference.