Since the last time I posted it here, I've made some changes. Everything is rebased on top of what is now PR #201 (it's not really severable from that).
https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte Now that resumption is PSK-based, some of the language might need tweaking for that, but I not everything is sorted out for PSK-based resumption yet. (there's TODOs in the draft; e.g., doesn't yet say what cipher suites are to be used for resumption) Other than that, it's at a state that (with PR #201) I could submit a PR if we can agree that this is the general path forward. The highlights of this proposal, for those who didn't follow the previous (long) discussions on the topic: * All DH, DHE, ECDH, RSA, and DSS cipher suites are deprecated. (some could still be offered for backwards compatibility, just like before) * The only compatible cipher suites would be those with a handshake portion of ECDHE_ECDSA, ECDHE_PSK, PSK, or ECDHE_anon. (there is an exception in there for completely new stuff, which will essentially be amending this anyway) * All ECDHE_ECDSA suites can negotiate ECHDE/DHE & ECDSA/DSA/RSA via the existing extensions. (no new extensions need to be defined to do this) * Likewise, ECDHE_PSK and ECDHE_anon can negotiate ECHDE/DHE via the existing extension. * A new standards track RFC to promote ECDHE suites from informational is needed, but that was already true. * In addition to reducing combinatorial nonsense with the suites, it results in deprecation of existing DHE suites in favor or DHE done via ECDHE labeled suites only with strong groups. This is the general result of previous discussions. The alternate route that came up was just to ditch the concept of cipher suites entirely and add a new extension to negotiate the AEAD cipher/hash to use with the existing extensions. There's nothing that would preclude moving to that more extreme route if this were to be accepted first, as ECDHE/DHE negotiation via the extension would be needed for that too. I think the WG is more in favor of the route proposed in this changeset at the moment, though. Dave _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
