On 2/20/2019 3:06 AM, Dmitry Belyavsky wrote: > > > On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky <beld...@gmail.com > <mailto:beld...@gmail.com>> wrote: > > > > On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann > <pgut...@cs.auckland.ac.nz <mailto:pgut...@cs.auckland.ac.nz>> wrote: > > Dmitry Belyavsky <beld...@gmail.com > <mailto:beld...@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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
