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

[Jacob Appelbaum <[e-mail]>]

On 12/4/15, Peter Gutmann <[e-mail]> wrote:
> Jacob Appelbaum <[e-mail]> writes:
>
>>TCP/IP and DNS are out of scope, though obviously related.
>
> Why are they out of scope?

They are out of scope for the TLS working group as far as I understand
the organization of the IETF in terms of mandate. Am I incorrect?
Should we discuss the privacy failures of IPv6 on this list as well?
I'm happy to do so but I think this is out of scope.

> You can't just ignore a threat if it's
> inconvenient, you need to look at the overall picture.

That is exactly what I've been saying over the last several days and
really for many years. The collective action failures here are not
because I can't see the overall picture but because there is blame
shifting. If we look at one specific protocol and solve things, we
find that composed with other solutions, we're really working toward
an overall solution.

> Arguing over
> plugging
> a mousehole in the corner of the barn is pointless when two of the four
> walls
> are missing.  As Martin has pointed out:
>
>   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.

TLS protects the HTTP headers, bookmarks don't travel across the
network and a url needs to be sent by a protocol to be leaked to the
network. The client requested hostname is leaked a single time.
Plugging that leak by encrypting it is not impossible and that someone
might share a URL doesn't mitigate the usefulness of reducing that
specific information leakage in TLS.

The point is not to hide that a server has a name - the point is to
protect a flow within a relevant time frame. This may prevent an
adversary from selecting it for storage (ex: XKeyscore selector on
cs.auckland.ac.nz) or it may prevent an adversary from doing an active
attack from even as lowly as an off-path position having seen just a
single or small subset of packets from a given flow. There are other
reasons as well.

That DNS has problems doesn't mitigate that TLS itself has problems
when it stands alone.

>
> I'm not sure if I'd call it crazy and pointless, just not worthwhile.
> You're
> leaking server-name information in a great many other locations and ways,
> and
> encrypted SNIs causes so many problems, that the cost/benefit tradeoff
> doesn't
> make it worthwhile (which, I guess, could be classed as "pointless").

As a TLS user - I'm only leaking SNI at Tor exit nodes and there is no
other choice for me. I'm living in the world where DNS and other
channels are not leaking on the same path as my TLS connection. Still,
my TLS connections have a lot of information that is available to a
sniffer on a Tor exit or XKeyscore on the whole internet. Removal of
the SNI field is not an option - encrypting it should be an option, if
not a strong default.

>
> Perhaps someone could write an RFC for a play-with-experimental-features TLS
> extension, where implementers could encrypt lengths and SNIs and anything
> else
> they want, and then test them out in the real world to see what effect it
> has.

Or they could just call MinimaLT or CurveCP with mandatory Elligator
TLS 1.3 and be done with it.

All the best,
Jacob