Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt

[Dave Garrett <[e-mail]>]

On Wednesday, June 03, 2015 04:50:59 pm Tony Arcieri wrote:
> That said, I think everyone is convincing me FFDHE *might* be a good idea.
> Particularly persuasive is Ilari's argument that with some tiny changes,
> ECDHE and FFDHE can be unified.

Actually, doing that completely is probably better than adding new suites. Just do "DH(E)_*" diediedie and allow new implementations that negotiate "ECDHE_*" to pick either a strong curve to do ECDHE or a strong group to do FFDHE, without needing to specify it in the suite.

Back in the discussion about ways to improve negotiation of capabilities to deal with the suite combinatorial explosion, the general consensus was that the simplest a la cart route would be to only negotiate symmetric ciphers via the suites and pick the rest via extensions, ignoring the parts in the suite. The usage of FFDHE or ECDHE would be based on what gets negotiated via the “supported_groups” extension. This could be the general way forward for TLS 1.3+ and for older TLS clients that want to deprecate "DH(E)_*" suites as well.

With this route, all endpoints that negotiate the use of the “supported_groups” extension would:
1) Consider all "(EC)DHE_*" suites to be equivalent; any *DHE* suite would use the same negotiation algorithm. (ephemeral only might be simplest; just ditch non-FS)
2) Usage of FFDHE or ECDHE would be chosen based on the negotiated named group/curve based on client priority.
3) Endpoints that no longer wish to ever negotiate any weak DHE would stop offering all "DHE_*" suites, which would now be considered deprecated.
4) The "ECDHE" prefix on suites would now essentially mean "ECC capable", rather than "only ECC".


Dave