A la carte concerns from IETF 93
Dave Garrett <davemgarrett <at> gmail.com>
2015-07-22 20:10:27 GMT
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:
+ 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
+ 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
- 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)
+/- 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:
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:
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:
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.