On Wed, Feb 20, 2019 at 03:48:18PM -0800, 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. 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.
There's prior research on embedding covert signaling into TLS as a means of preventing blocking by middleboxes. The work I'm familiar with is in the field of decoy routing or refraction networking. There's a list of papers at https://refraction.network/ and there's a good survey in Section 2 of https://censorbib.nymity.ch/#Manfredi2018a. Telex (https://censorbib.nymity.ch/#Wustrow2011a) is a good representative example. Omitting some details: A router has a private key r. On a new connection, the client generates a temporary private key s. The client sets the Random field in its Client Hello to g^s || H(g^(rs)) for some hash function H. The server, knowing r, can distinguish this value from random, but other observers cannot. (There are additional tricks to make g^s uniformly distributed.) Lately the research has been less about the specific means of covert signaling, and more about improving security and deployability, for instance by working of asymmetric routes, or requiring only injection and not flow blocking. There's been an ISP-scale deployment of one of the designs, called TapDance: https://censorbib.nymity.ch/#Frolov2017a. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
