Oh brother, sorry about not seeing that, I will re-read and resend. -tom
On 23 May 2014 09:00, Yaron Sheffer <[email protected]> wrote: > Hi Tom, > > Thank you for your comments. Can you please read (or skim) the companion > document [1], and resend your comments within the context of both documents. > > Thanks, > Yaron > > [1] http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00 > > > On 05/23/2014 02:42 PM, Tom Ritter wrote: >> >> 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 >> > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
