Subject: [Secdispatch] 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