On 12/3/15, Martin Rex <m...@sap.com> wrote: > Jacob Appelbaum wrote: >>> >>>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >>>> secure >>> >>> That is a myth. >> >> Are you asserting that TLS 1.3 will be less secure or equally secure >> here? > > Even TLSv1.0 is sufficiently secure already, so that there > are plenty of other attack surfaces *MUCH* easier to attack. > > http://www.schneier.com/books/practical_cryptography/preface.html > > Arguing about whether a key should be 112 bits or 128 bits long is > rather like pounding a huge stake into the ground and hoping the > attacker runs right into it. You can argue whether the stake should > be a mile or a mile-and-a-half high, but the attacker is simply going > to walk around the stake.
I look forward to using that poor saps TLS 1.0 services - where TLS isn't the weakest link! > If you design anything around TLS where the "secrecy" of the servername > is important, then you are acting extremely irresponsible. There are so > many ways and places where the servername WILL be leaked, (URLs, bookmarks, > HTTP-Header-Fields, HTTP-Referer headers, etc.) that bottom line, > encrypting > SNI amounts to crazy and pointless idea. > Huh - Could you please enumerate all of the places that TLS leaks a hostname requested by a client? Each one of them is a problem and we should correct it. TCP/IP and DNS are out of scope, though obviously related. > Using sha1(servername) instead of servername is (a) not confidential > and (b) backwards-incompatible with the existing protocol&usage and > the installed base. That was not a serious suggestion. If you think that I seriously suggested hashing the server name, I'm sorry. Please re-read my email and understand that I was suggesting that we can change the value of a field easily to make the attack more expensive. To make it worth doing, we want a better scheme than a straight hash of a name, of course. > No matter how many hoops you jump, encrypting > SNI will never become anything close to a TOR hidden service. > And for the vast majority of servers, there is going to be such > a small number of virtual services, that distinguishing them will > always be trivial by their traffic patterns. There is nothing that > TLS could do about app-determined traffic patterns of unrelated > TLS sessions. We probably agree here - there is a case where you want to compose with Tor. However there is a different issue which is that by leaving the client requested name in the clear, an attacker, even against a Tor exit node, can denial of service a specific client with nothing more than a word list. This is no different from HTTP without TLS for tearing a connection down; it becomes different with TLS 1.2 and DTLS (and probably with something like Bryan's super encryption). Sadly, DTLS doesn't compose with Tor and so, we want a similarly hard to distinguish TCP protocol that does compose with Tor. None the less - eventually a long term attacker may be able to learn things about public websites (eg: which wikipedia page you visited) - for non public websites, I don't believe that you can make the same claim. Additionally, the bar for an attack has just been seriously raised from ngrep to a pretty sophisticated attacker with long term funding. > You could use innocent servernames or multi-SAN server certs plus *NO* SNI. > and both would provide higher security and be much easier to implement > than encrypting SNI. I look forward to your proposal that removes the need for encrypting SNI. I think it will be interesting to compare your construction with the soon to be shown encrypted SNI proposal. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
