[TLS] A la carte concerns from IETF 93

[Dave Garrett <[e-mail]>]

Consensus was my current WIP proposal is not viable, for some of the following main reasons:

1) cost/benefit analysis doesn't seem to be worth it
2) backwards compatibility handling
3) some argue harder to implement; others argue easier

To start, I'll note that I have not submitted a PR yet.

This is all currently just on a WIP branch on GitHub to be easier to discuss specifics on-list. It's based on PR #201, but that's just to make keeping track of things easier. This is less of an issue now that my other PRs were merged (namely the updated cipher suite section).

I'll switch to a standalone proposal for the next draft instead of editing the section inline, as it was indicated that would be easier to follow. Not everyone was a party to every discussion on-list about these topics, so a better summary is needed.

On to the concerns:

1) The cost/benefit analysis is a very important concern. If you're only analyzing this from a perspective of combinatorial explosion reduction, then I actually agree it's not worth the cost. Here's how I perceive it, currently:

benefit:
+ reduction in combinatorial mess (primarily achieved as we move forward, as back compat still needs to offer some old)
+ single point of negotiation for (EC)DHE
+ single point of negotiation for certificates (seemed to be wide agreement to do this regardless of full a la carte)
+ deprecation of existing DHE suites which risk wanting weak groups depending on server and are an interop hazard due to Java being crap
+ ECC is always an option, regardless of suite offer/selection
+ FFDHE doesn't need new suites to be offered by clients not offering DHE AEAD at the moment
+ missing combinations are no longer an interop failure

cost:
- change has risks of mistake at various points (implementation, deployment, admin, client config, etc.)
- support for TLS 1.2 + 1.3 results in a mix; old suites still need to be offered
- risk of confusion due to change in behavior (point #2 above)

depends:
+/- point #4, depending on implementation

(the number of points in this list is not indicative of weight; the first cost could outweigh all benefits, depending on perspective)

Additionally mentioned cost:
- cannot specify exact combinations; some might not be desirable

However, I set this one aside because it's a problem with a full a la carte proposal, but not my current one. All possible combinations of DHE/ECDHE+RSA/DSS/ECDSA/PSK/anon+cipher_hash are already considered valid, and generally have their own suite assignments. I'm not suggesting breaking up cipher_hash. Cert/PSK/anon still have to have separate suites in this system, which prohibits wrong stuff like none_anon (lack of DH from plain PSK + anon). If we ditch suites entirely, as was suggested by others, then this is a risk that comes up.

The main difference in my calculus vs. others is that:
a) I'm swayed by Tony Arcieri's argument that DHE, as it currently exists, needs to be scrapped. Old Java chokes on it and there is a risk of servers negotiating weak groups when offering it. Deprecating all DHE suites is an interop and security win. FFDHE is still around, but now with only strong groups, whereas without this proposal we go ECC or bust (until something post-quantum is a viable option here).
b) ECC isn't separate anymore; it's always expected to be available. We don't have to worry about endpoints actually offering suites that claim support, as it's just a given now.
c) Interop failure due to missing suites, regardless of algorithm support, is no longer a risk. It's currently possible to negotiate CBC because the GCM suites offered by the server are combinations not supported by the client, even though GCM is supported. (this does happen in the real world and is too often overlooked in this discussion)

2) Backwards compatibility is pretty straightforward.

Here's what Firefox currently offers, minus RC4 & 3DES:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

The current TLS 1.3 draft would only accept the top two as viable (only AEAD). Both my current proposal and the general consensus minimum would pick just the top one and pick certs based on the extension.

Note that DHE/FFDHE is available, but only for AES CBC with RSA. The second change here is that my proposal allows DHE with no changes to this list. Yeah, we'd like to move to an ECC only world, but I'm paranoid and want a backup. This gives it effortlessly. This would also permit FFDHE+ECDSA combinations without new suites. All DHE suites could be dropped in the future, in favor of ECDHE only on old TLS but the possibility of FFDHE on new. If you want to keep around FFDHE without this proposal, you need to add those suites for GCM.

Just to make sure it's emphasized, the current path without this proposal would require Firefox add the following in order to use the new FFDHE groups:
TLS_DHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Mozilla probably doesn't want to do that. Negotiating the new FFDHE groups might be acceptable, but whatever weaker junk you get without them is not. I guess a higher minimum could be put in place for AEAD suites or TLS 1.3+, but now we're already adding complexity.

Once we get out of the AES monoculture, it's also the difference between adding:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_DHE_RSA_WITH_CHACHA20_POLY1305
TLS_DHE_ECDSA_WITH_CHACHA20_POLY1305
or just:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

I'll also add that DHE_ECDSA suites just aren't defined. Yes, using the cert extension could let us get this combo via DHE_RSA, but that means offering RSA suites for everything old and new.

As to the need to list all this stuff to work:
If you want everything to be clean, abandon TLS and go for something QUIC based. Backwards compatibility is messy; that's one of the reasons why you shouldn't want it forever.

3) I argue that framing the negotiation in a manner more similar to what is actually being negotiated reduces the risk of problems. _Not_ doing so has the following issues:

a) Offering an ECDHE suite will offer FFDHE groups via the upgraded extension, but no ability for a server to pick it if the right combo for DHE isn't there. The server can't select the 4k FF group if it'd rather have that than P-256 because no better curve is available.
b) ECHDE/DHE has to be chosen based on cipher suite priority, rather than actually looking at the groups' priority and picking the one that should be preferred. Contrary to suite definitions, ECDHE and DHE are not monolithic things.
c) The server should be able to offer any certs the client can use, regardless of connection encryption. (again, this part seems to have wide agreement)

---

That covers the main issues. There's also the issue of making sure that any new system is understandable and doesn't introduce points of confusion down the road.

I don't claim that this addresses everything that has been or can be said, but I also don't want to post a larger wall of text than this. ;)

Also, others may likely not care about FFDHE as much as I do. It is, however, in the current draft on essentially equal footing with ECC. As such, I'm considering it that way in discussion and proposals. This proposal is shaped by the negotiated FF-DH draft and its integration into the current TLS 1.3 draft.


Dave