Carrick Bartle <cbartle...@icloud.com> wrote: > I think the blanket prohibition of reuse of ECDHE keys is maybe not > really justified. > > Why is that? >
PFS isn't all-or-nothing. I do think each key should be used when practical, although I don't know why it would be bad to reuse a key for a very short period of time. E.g. if one has a key, and as soon as it is used once, asynchronously kicks off the generation of its replacement, then using that key until the replacement has been generated seems OK to me. Things get more problematic the longer/more the key is reused. IMO that's the part that should have deprecation of RSA cipher suites done > at the same time. > > RSA seems to me to be too off-topic for this draft. (It also seems to me > that RSA is still too widely used and not broken enough to merit > deprecation.) If you think this draft requires that RSA key exchange also > be deprecated, that could be done in a parallel draft. > RSA is on-topic because deprecating DHE cipher suites quite directly leads to more use of RSA key exchange. There's already evidence of this from Firefox, where they had to enable more RSA key exchange cipher suites immediately after disabling the DHE cipher suites. It is true that RSA key exchange is widely used; the purpose of deprecating it is to put political pressure on implementers to make it less widely used. That's the whole point of these deprecation RFCs. RSA is the worst key exchange mechanism in TLS w.r.t. to PFS, which is the reason the paper cites for avoiding ECDH key reuse for ECDHE cipher suites. Why is it horrible to reuse an ECDH key a few times but it's OK to reuse an RSA key millions of times? Is RSA "broken enough"? That goes back to my point that while in theory one could do a perfect job of protecting their server's private keys, in practice many will fail at it. That's why we mandated PFS cipher suites in TLS 1.3 and in HTTP/2, to reduce the harm in losing control of the private key. The draft makes the good point that it would be hard to secure a DH(E) implementation against timing attacks. But, RSA is the *hardest* to secure key exchange mechanism w.r.t. timing attacks. Not only does it require very careful coding within the core crypto library, but it also requires very error-prone and non-obvious logic within the TLS implementation. Raccoon mitigations wouldn't require that. (For the record, the difficulty of mitigating the timing side channels mentioned in the Raccoon paper seems to be quite overstated. We could all do it if we wanted to.) Anyway, to be clear, I'm not advocating for DHE cipher suites in TLS 1.2. I'm advocating against encouraging more use of RSA cipher suites, and I'm against encouraging the continued use of TLS 1.2 in general. Deprecating (EC)DH(E) key exchange without deprecating RSA has the rhetorical effect of saying RSA key exchange is not as dangerous as (EC)DH(E); I don't think that's true at all. Things need to upgrade to TLS 1.3 and things need to drop RSA key exchange in favor of forward secret key exchange. Cheers, Brian
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
