Re: [TLS] About encrypting SNI

[Viktor Dukhovni <[e-mail]>]

On Tue, May 20, 2014 at 01:24:12PM -0700, Tim Bray wrote:

> Let?s assume you are correct in all your assertions.  It is still the case
> that every time you increase the proportion of the attack surface which is
> encrypted, you increase the difficulty for snoopers. It is not a
> requirement that you make the snoopers? task impossible; in fact, all you
> can ever do is crank up the difficulty for attackers. It seems obvious that
> encrypting as much of connection setup as possible would increase attacker
> difficulty so, if practical, it should be done.

This runs smack into the "mile-high pole" fallacy.  Quoting Bruce Schneier:

    Secure the Weakest Link

    You can't just plant a mile-high pole in front of your castle
    and hope the enemy runs right into it; you have to look at the
    whole landscape and build earthworks and a palisade.  Similarly,
    just because you're using an encryption algorithm with a 256-bit
    key doesn't mean you're secure; the enemy is likely to find
    some avenue of attack ignores the encryption algorithm completely.

In particular stronger security measures that focus on a small part
of the problem often yield no measurable benefit.  This is quite
likely the case here.  I would not want to encourage any user whose
life or well-being depended on security of TLS against traffic
analysis to even consider relying on TLS SNI encryption.  Such users
need to be substantially more cautious.

The only plausible use-case for SNI encryption is to thwart bulk
traffic analysis directed at entire populations, users likely to
be targeted MUST NOT rely on protection as feeble as an encrypted
TLS handshake might yield (yes, if it is possible at tolerable
cost to not aid the attacker AND there is a reasonably plausible
measurable benefit as a result, one should still implement the
protection).

So this boils down to whether:

      Is it in fact plausible that all the various counter-measures
      were they rolled out (over a decade or two), in multiple
      protocols and implementations, would provide the expected
      benefit by making traffic analysis measurably more difficult?

I am regrettably skeptical of this.  I think we could make more
progress by obviating the need for SNI than by attempting to encrypt
it.

For example, with DNSSEC SRV records, the TLS service endpoint for
a hosted domain can be mapped to a fixed hosting name that does
not depend on the hosted domain name, and the client could verify
the single name in the server certificate.  If we move to an SNI-free
world, the problem is eliminated from TLS.  There are still DNS
queries to protect, but these would need to be protected anyway (the
A record lookup).

Of course SNI is almost certainly not the only sensitive payload
in the handshake, and one might want to define a stripped-down
outer protocol that completes an ADH or AECDH key exchange with
channel binding first to an SNI-agnostic TLS stack at the target,
and then sub-negotiates with channel binding any additional protection
that may be desired.  Such a protocol would sport mandatory session
tickets for fast reliable resumption, with a lifetime advertised
to the client to avoid needless fallback latency to the full outer
protocol.  Resumption would begin with an outer session ticket and
an encrypted inner handshake (which might also be a resumption).
If outer resumption does fail (should be rare), the server would
elicit a new full outer handshake from the client, without requiring
the client to disconnect and retry.

This would be a dramatic change, would one still call such a beast
TLS?

-- 
	Viktor.