Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[[e-mail] (Martin Rex)]

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