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

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 19 Feb 2019 23:04:06 +0300

Hello,

Please take a look at an initial submission of the draft.
The draft describes a Fake SNI mechanism intended to cheat DPI systems in
a case
when a DPI system blocks the connection if ESNI is present.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Feb 19, 2019 at 10:43 PM
Subject: New Version Notification for draft-belyavskiy-fakesni-00.txt
To: Dmitry Belyavskiy <[email-masked]>

A new version of I-D, draft-belyavskiy-fakesni-00.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:           draft-belyavskiy-fakesni
Revision:       00
Title:          Fake Server Name Indication
Document date:  2019-02-19
Group:          Individual Submission
Pages:          3
URL:
https://www.ietf.org/internet-drafts/draft-belyavskiy-fakesni-00.txt
Status:         https://datatracker.ietf.org/doc/draft-belyavskiy-fakesni/
Htmlized:       https://tools.ietf.org/html/draft-belyavskiy-fakesni-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-belyavskiy-fakesni

Abstract:
   The document provides a specification of the Fake Server Name
   Indication.  Being implemented, the Fake SNI specification provides a
   way to work around the monitoring solutions without providing any
   additional information to external observers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
SY, Dmitry Belyavsky

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Feb 2019 03:43:56 +0000

Dmitry Belyavsky <[email-masked]> writes:

>The draft describes a Fake SNI mechanism intended to cheat DPI systems in a
>case when a DPI system blocks the connection if ESNI is present.

Since this mechanism advertises the fact that a fake SNI is present, wouldn't
the DPI then also block the connection for that?

Peter.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 20 Feb 2019 10:01:34 +0300

Dear Peter,

On Wed, Feb 20, 2019 at 6:43 AM Peter Gutmann <[email-masked]>
wrote:

> a

The suggested mechanism does not advertise the presence of a Fake SNI.
Fake SNI is delivered out-of-band for the handshake and an observer has to
discover
that ClientHello message contains a SNI extension that does not match to
any host
present at the IP address where we try to connect.

Passive collection and blocking the Fake SNI values also has little sense
because the value can be changed relatively easily.

-- 
SY, Dmitry Belyavsky

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Feb 2019 07:21:20 +0000

​Dmitry Belyavsky <[email-masked]> writes:

>Fake SNI is delivered out-of-band for the handshake

But then won't the DPI check the out-of-band source as well?  If you've got a
MITM sitting there then they can do the same lookups and whatnot that the
client does, unless you're relying on the client being off-path, which seems a
bit of a leap.  You'd need to implement it via some sort of subliminal
signalling mechanism that the DPI can't detect.

Peter.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 20 Feb 2019 10:35:34 +0300

> signalling mechanism that the DPI can't detect.
In fact if DPI begins to poll domains whether FakeSNI record is present,
we have a race between changing the value in FakeSNI and DPI polling.
And DoH/DoT ensures that DPI has to poll.

-- 
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 20 Feb 2019 14:06:20 +0300

> And DoH/DoT ensures that DPI has to poll.
Let me clarify. I understand that the solution I propose is not perfect.
But there is no silver bullet, and this is just another way to make a life
of DPI harder.

-- 
SY, Dmitry Belyavsky

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Feb 2019 15:48:18 -0800

On 2/20/2019 3:06 AM, Dmitry Belyavsky wrote:
>
>
> On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Dmitry Belyavsky <[email-masked]
>         <mailto:beldmit@gmail..com>> writes:
>
> But there is no silver bullet, and this is just another way to make a
> life of DPI harder.

Out of all the requirements listed in the encryption requirements draft,
the requirement to "not stand out" is probably the hardest to comply
with. 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.

-- Christian Huitema

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Feb 2019 23:51:05 +0000

It’s an arms race, privacy against inspection/blocking.  There’s no way to avoid it. IETF specs being open documents freely available make the “good guys” job a little harder, maybe. :)

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Feb 2019 23:51:34 +0000

Christian Huitema <[email-masked]> writes:

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

I'd thought about that too, thus my comment about subliminal signalling, the
problem is that if you've got a standardised subliminal message than it's not
really a subliminal message any more.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Feb 2019 00:39:56 +0000

On 20/02/2019 23:48, Christian Huitema wrote:
> 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

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