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

[Jacob Appelbaum <[e-mail]>]

On 12/2/15, Martin Rex <[e-mail]> wrote:
> Jacob Appelbaum wrote:
>> On 12/2/15, Martin Rex <[e-mail]> wrote:
>>>
>>> So your client will have to know a-priori, out-of-band or be configured
>>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello
>>> with cleartext SNI.
>>
>> I think that is false. One could easily use the "cleartext" SNI field
>> and insert an encrypted value. A hash of the name would be a simple
>> example but not a secure example, of course.
>
> No you can NOT do this (in TLSv1.2 and earlier), because it is entirely
> backwards-incompatible.

If I configure a vhost to respond to a sha1(example.com) and have a
way to visit sha1(example.com) in a browser, I think it doesn't even
break the spec. That doesn't really matter - the point was to suggest
that there are many ways to solve this problem. Assuming a shared key,
we can easily take a field and transform it. There are compelling
reasons to do it and there are active attackers who are exploiting the
lack of confidentiality in TLS.

>
> Server-side SNI can even be implemented completely outside of the TLS
> protocol stack (that is how I implemented it).

I'm curious - are you saying that if the value was encrypted... it
would become impossible to implement it outside of the TLS protocol
stack? Or is this just an aside?

>
>>
>> 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?

>>
>> and in ways that will only become worse over time. We should
>> remember that TLS 1.3, while not yet finished or deployed, is a future
>> legacy protocol.
>
> TLSv1.3 is looking more and more like a future market failure to me,
> worse than IPv6.

Without privacy on the internet, I'll see your market and raise you a TCP RST.

All the best,
Jacob