I've read -00[0], and had the following feedback. 1) Is the intent merely to document attacks, or provide Best Current Practices? For instance, the BEAST attack does not actually say explicitly "Servers SHOULD offer TLS 1.1 and above to mitigate the BEAST attacks."
2) Is there a reason that many attacks on TLS are omitted? I don't consider this a comprehensive document for deploying TLS on a webserver. In particular, I would have expected information on securing deploying a configuration that also avoids: - The ECC algorithm confusion attack - Triple Handshake - Secure Renegotiation - Browser-based protocol downgrade to the extent it can be - TLS-based Denial of Service to the extent it can be - TLS stripping (And using HSTS to prevent) - Certificate Forgeries, and using PKP to mitigate 3) On the flip side, I actually consider Lucky 13 OUT of scope. Lucky 13 and other implementation errors[1] are the concern of people _implementing_ TLS. People deploying TLS should be certain they do not choose an implementation of TLS that is vulnerable to these attacks, and it's worthwhile providing a recommendation on that. I'm not certain it's worth trying to enumerate patched versions of libraries, because vendors backport patches, but a general statement would be appropriate IMO. If implementation concerns are in scope, we have a number of them also omitted. 4) Then again, I do consider it a 'Best Current Practice' not to deploy a server that does not meet the TLS spec. In particular, the deployment of servers that are intolerant of long handshake messages, ciphersuites or extensions they don't recognize, or that hang on newer versions of TLS make life very difficult for us. 5) Is DTLS in or out of scope? Presumably a number of TLS options are also out of scope: PSK, OOB, SRP, Client Certs, OpenPGP, Kerberos.... 6) I consider providing OCSP information, stapled in the response, to be a 'Best Current Practice'. 7) There is nothing about ciphersuite selection. Like #6, I consider using PFS a 'Best Current Practice'. But at the same time, ECDHE is way better than 1024-bit DHE. (Which is also not mentioned.) FWIW, I think http://armoredbarista.blogspot.com/2013/01/a-brief-chronology-of-ssltls-attacks.html is an excellent resource worth referencing as well. -tom [0] http://tools.ietf.org/html/draft-ietf-uta-tls-attacks-00 [1] Implementation Concerns: Timing attacks that disclose private keys (the Bleichenbacher attack, targeting square-and-multiply, the equivalent for ECC, etc), Lucky 13, Heartbleed, others _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
