Peter Saint-Andre - &yet <[email protected]> wrote: > On 11/11/14, 9:10 PM, Brian Smith wrote: >>> o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >>> >>> o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>> >>> o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >>> >>> o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> >> I generally agree with these recommendations, but I think it is >> inappropriate to recommend that clients support >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or >> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 at this time.
> Do I understand correctly that you would recommend the ECDHE > ciphers but not the DHE ciphers? > Or would you recommend some other DHE ciphers? Because of the various serious problems with DHE key agreement that are mentioned in the draft (and some not even mentioned in the draft), it doesn't make sense to recommend the TLS_DHE_* variants of the AES-GCM cipher suites like the TLS_ECDHE_RSA_* variants are recommended, or for them to be recommended more highly than the TLS_ECDHE_ECDSA_* variants, which currently aren't recommended at all. It is important for servers to support TLS_ECDHE_* (with ECDSA certificates) to support Windows SChannel-based applications, because Windows SChannel has a large marketshare (all of MSIE, MS Outlook, etc.), and Windows SChannel does not support TLS_ECDHE_RSA_* until Windows 10. Similarly, it is important for clients to implement them due to the large marketshare of MS Exchange and IIS. Further, my opinion is that clients SHOULD NOT enable TLS_DHE_* or TLS_RSA_* cipher suites at all, unless they know they need to interoperate with servers that only support those cipher suites. But, if you are going to enable TLS_RSA_x, then you should also enable TLS_DHE_RSA_x for all x, and clients should ensure that the server's DHE key meets minimum security criteria that aren't currently defined in the draft, and clients should probably implement a fallback mechanism for when the server uses a DHE key that does not meet the minimum security criteria. >> A BCP defining cipher suite recommendations should not have a higher >> level of requirement for TLS_RSA_WITH_AES_128_CBC_SHA than it has for >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, at least. I think it is OK to just >> say that the TLS specification was wrong to mandate >> TLS_RSA_WITH_AES_128_CBC_SHA, or don't mention it at all. > > I don't know if RFC 5246 was *wrong*, but the situation on the ground has > changed since 2008. Right. My point is that it is strange, for example, to have TLS_RSA_WITH_AES_128_CBC_SHA be mandatory, while TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is only recommended, and when TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 isn't even recommended. Cheers, Brian _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
