Hi Brian, I'm not seeing what part of your email is new and not something already discussed by the WG. Can you clarify?
Thanks, S. On 03/12/14 01:59, Brian Smith wrote: > 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 > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
