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

[Jacob Appelbaum <[e-mail]>]

On 12/3/15, Martin Rex <[e-mail]> 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