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

[Christian Huitema <[e-mail]>]

On 2/20/2019 3:06 AM, Dmitry Belyavsky wrote:
>
>
> On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Dmitry Belyavsky <[e-mail]
>         <mailto:beldmit@gmail..com>> 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.
>
>      
>     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.
>
>
> 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.


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