Re: [TLS] ESNI padding the Certificate message

[David Fifield <[e-mail]>]

On Thu, Dec 13, 2018 at 11:02:54AM -0500, Viktor Dukhovni wrote:
> On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote:
> 
> > Random padding does poorly with repeated trials. So, for instance,
> > if I get to observe a large number of requests from the same client
> > to the same server, you can gradually infer the length of the cert
> > chain.
> 
> Yes, I was aware of this.  But one might also note that may services
> are not behind a CDN, and that data traffic patterns after the
> handshake can also fingerprint the target service.
> 
> Session resumption helps to reduce the number of full handshakes
> that leak some information about the certificate size.
> 
> Users who really want (better) protection against traffic analysis
> should use Tor.  TLS traffic analysis protection from ESNI et. al.
> is IMHO best-effort protection for casual use.
>
> If a user visits just one site (and no others) at a particular CDN,
> absent traffic flow obfuscation ala Tor, the user's TLS traffic
> will eventually stand out from the noise.

Tor does not really offer protection against traffic analysis, apart
from hiding the source and destination IP addresses. In fact a lot of
website fingerprinting research uses Tor as a carrier, *because* it
preserves features of the underlying flow. See for example Table 1 at
https://petsymposium.org/2018/files/papers/issue4/popets-2018-0039.pdf#page=3
Tor pads most of its cells to 514 bytes (https://spec.torproject.org/tor-spec §0.2 §3),
and fairly recently (Tor 0.3.1.7, 2017-09-18) it sends padding cells
during quiet periods in order to collapse long-term netflow records
(https://spec.torproject.org/padding-spec §2), but neither of these are
designed to defend against website fingerprinting attacks; on the
contrary, they introduce fingerprints that make it easier to detect the
use of Tor inside a tunnel.

Don't miss an important use case. Tor and ESNI are not mutually
exclusive. A user may want to use ESNI in order to *reach* Tor (or any
other service offering additional security properties). ESNI is not just
for HTTPS web pages; it's for any TLS service (or service that can be
tunnelled in TLS). But any such service is useless if an intermediary
can block the server hosting it. This is where ESNI can be of help.

I wouldn't put repeated trials to infer a randomized value, and analysis
of encrypted application-layer traffic characteristics, in the same
class of difficulty, and reason that if the latter is possible, there's
no reason to defend against the former. I think part of the reason that
Tor does not (yet) do traffic flow obfuscation is that it hasn't been
necessary. The networks that block Tor don't do it on that basis. That's
not to say it's not something to think about, just that empirically it
hasn't proven as pressing as other considerations. Things like Cisco ETA
(https://www.theregister.co.uk/2017/06/22/ciscos_encrypted_traffic_fingerprinting_turned_into_product/,
https://github.com/cisco/joy#relation-to-cisco-eta, https://arxiv.org/abs/1607.01639)
show the commercial world at least reaching for such capabilities, but
my understanding is that it's still far short of an operational
"identify this HTTPS site" feature.