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:
>>
>> I hope that we'll hide the SNI data by default and I understand that a
>> discussion about encrypted SNI is currently scheduled for some point
>> in the future.
>
> Hiding SNI data is completely silly security-wise, and any TLSv1.2
> backwards-compatible ClientHello must include a plaintext visible SNI.
>

Not hiding SNI data is completely silly security wise. SNI data is
used by attackers to perform denial of service attacks and to automate
man-in-the-middle attacks.

We have bare keys in TLS that may also be ephemeral - why would we
want to reveal a selector to the network that we know is used for
active attacks against the protocol?

The question for a few people, myself included, is how we might
protect the SNI data in an efficient manner.

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

To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less
secure 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. We shouldn't burden the future with the failures of
TLS 1.2 or any other SSL/TLS mistakes of the past.

All the best,
Jacob