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. 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. Using sha1(servername) instead of servername is (a) not confidential and (b) backwards-incompatible with the existing protocol&usage and the installed base. 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. 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. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
