Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

[Stephen Farrell <[e-mail]>]

On 20/02/2019 23:48, Christian Huitema wrote:
> 
> Out of all the requirements listed in the encryption requirements draft,
> the requirement to "not stand out" is probably the hardest to comply
> with. 

Yep. I think it'd be worthwhile spending a bit of time to see if
we could do better on that based on the esni -02 draft and how
we guess that'll evolve. The ESNI greasing PR would help here as
it'd mean plenty of ESNI extensions in ClientHello's if people
really did grease in sufficient numbers. If that got to the level
where blocking all ESNI wasn't feasible, then maybe that's good
enough.

But there is something attractive about a stealthy-ESNI scheme
so maybe it's worth spending a bit of time trying to see if we
can find one. I'd be up for taking a shot at that in Prague if
any other interested folks'll be there, are familiar enough
with esni-02 and it's PRs and would like to give it a shot over
a beer. (Just informally, it's a bit of a stretch-goal I figure,
so not worth getting excited about for now - anyway ping me offlist
if you'll be there and would be interested and I'll suggest a
time/place for a stealthy beer & chat.)

> The current ESNI draft works but usage of ESNI can still be
> detected. As Dmitri points out, there are locales where standing out
> will enable censorship. So, what to do? Well, if we want to not stand
> out yet carry some information, that's pretty much the definition of a
> hidden channel.
> 
> Would it be possible to engineer a hidden channel in the TLS 1.3 Hello?
> I bet that's quite doable. I am sure that fields like "opaque
> Random[32]" or "opaque legacy_session_id<0..32>" could be used
> creatively, and there are other fields in common extensions that could
> also be of service. Of course, "could be done" does not mean that the
> IETF will want to standardize it.

Right. And even if the IETF did want to standardise something,
that doesn't mean people would implement nor deploy. It's a
hard problem. Dave Plonka and I were chatting over beer recently
and came up with the idea below that we raised offlist with a few
folks who're interested in ESNI. It got a "mixed" response is
the best I could claim, where "mixed" varied from some enthusiasm
from one person to a very clear "no, don't like/want that" from
another but with silence in-between (the silence being the real
killer;-)

But maybe if we get a few folks and beers together a better
analysis will emerge...

Cheers,
S.

The idea is an extension to the ESNI scheme that can work in some
cases, is more bandwidth efficient and is stealthier in that one cannot
tell just from passively watching one TLS h/s that ESNI is in use.

Unless all the conditions required below are met, ESNI works according
to the (evolution of the) -02 draft. (I.e. if you can, then do this,
if not, use the approach that's in -02 or whatever that turns into.)

The TLS client needs to have a working IPv6 address.  The TLS server
needs to be contactable on any address that matches its /64 prefix.
The TLS server probably needs to sort of randomly change the AAAA
it publishes in a yet to be determined manner. That might be like
an IPv6 privacy address or might have to be a new flavour of server
privacy address.

ESNI calls for a key share to be published in the DNS below the name of
the TLS server.  Let's call that public key share g^D. (Even if using
ECC, I find it easier to think in terms of multiplicative groups;-)
This is the same as the -02 draft.

Similarly, let's use g^A for the client key share in the ClientHello
and g^B for the server's equivalent share.

Assume that all public shares are from the same group, so g^AD makes
just as much sense as g^AB. (We'd need to mandate that the client
MUST first pick the group for g^A ignoring what's possible based on
ESNIKeys as we don't want the ESNI tail wagging the TLS1.3 dog.)

We add another (optional) field to the ESNIKeys RR value that contains
an IPv6 /64 prefix for the TLS server. And perhaps a flag that says
that clobbering the low-order 64 bits of the IPv6 address is ok, i.e.
a flag that says a client can use this trick instead of the (evolution
of) the -02 scheme.

The idea is to use g^AD and the TLS ClientHello random number to
encrypt (a truncated hash of) the name that would otherwise be sent as
an SNI value.

That encryption has to produce a 64-bit output.

The output of the encryption is used as the IID of the IPv6 address
used to contact the server.

So something like:

    Z = g^AD
    K = KDF(Z,client-random)
    IID = E64(K,H64(servername))

H64 could be a simple truncated SHA-256.
E64 could be 3-DES in ECB mode:-)

Instead of a client-chosen random challenge (as per the -02 draft), in
this case the EncryptedExtensions returned by the server contains the
full (non-truncated) hash of the servername.

Some notes on the above:

- layering, smayering:-)
- yes, this is IPv6-only which puts off at least some implementers
- yes, the server needs to know the hashed SNI ahead of getting
  the first flight from the client for this scheme to be workable
- yes, not all wildcard cert scenarios might work with this (but
  some would)
- if it's ok for the EncryptedExtensions ESNI value to be fixed
  per hidden server (as proposed above) then that maybe makes the
  split-server mode much easier and more realistic, but...
- the above may be vulnerable to some attacks from which the -02
  version doesn't suffer (e.g. that allow an attacker to confirm
  that a client's CH is for some hidden service if the bad actor
  has guessed the right server already) - pondering such needs
  more work