On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote: > How would this group feel about a proposal to address this by specifying in > the 1.3 specification that implementations must ensure that the strength of > the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? > Perhaps an equivalency rule for the MAC might also be in order? Apologies if > this is already resolved somewhere in the draft RFC. I looked but didn’t find > it.
I've had a changeset sitting around for a while for recommendations (not hard requirements) to match the strengths for key exchange and bulk cipher key size. (it was leftover from a batch of other work, long since merged) That said, I'm not actually sure what my opinion is on this anymore. It's been on my todo list to bring up a discussion. https://github.com/tlswg/tls13-spec/pull/296 There's complications here that make picking a matching number less than straightforward: 1) A main reason to switch to 256-bit ciphers is for post-quantum crypto, but all (EC)DHE is completely broken in that scenario. Bigger numbers there won't help in any meaningful way. 2) Neither AES-256 nor ChaChaPoly match up things perfectly, already. For PRF, AES-256 uses SHA2-384, not SHA2-512; ChaChaPoly uses SHA2-256. AES-256 also has a 128-bit block size. 3) There's more to group security than bits. For a start: https://safecurves.cr.yp.to/ At this time, I'm leaning towards sticking in a recommendation to prioritize the following groups, in this descending order: X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then lastly, ffdhe8192 and/or secp521r1 only as emergency backup (arguably, X448 belongs back here too) I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use for TLS 1.3+ and only support it for transition in older TLS. (this came up on-list a long while ago, but needs further discussion) I'd state secp384r1 and ffdhe6144 as "NOT RECOMMENDED" to bother with, but still permitted (or, alternatively, just not explicitly recommended and not recommended against). I'd make the recommendation that X25519 and secp256r1, in that order, be sent in first-flight key shares, unless prior expectations exist for the server that another group is desired or required. Implementations would of course be permitted to send a more conservative set, such as (instead or additionally) X448 and ffdhe8192 or secp521r1, but even though I think this might make sense for 256-bit bulk ciphers, I concede that it would likely be overkill that wouldn't really help. Those who want something stronger should probably be refocusing their effort on getting some kind of PQ key exchange standardized. Am I somewhere in the ballpark of what the WG might deem appropriate here? There has been a "TODO" note sitting in the draft to address this for quite some time, and I'd like to get something in here at some point. Just to restate: my goal here is a set of recommendations to narrow down the zoo, not hard requirements (beyond requiring ~128+ bit strength security). Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
