In case you missed here is a letter to Google and Amazon on the blocking of domain fronting by Senator Rubio and Wyden:
https://www.wyden.senate.gov/imo/media/doc/Wyden%20Rubio%20Letter%20to%20Ama...
Press coverage:
https://www.cyberscoop.com/domain-fronting-ban-letter-ron-wyden-marco-rubio-... https://www.accessnow.org/access-now-supports-bipartisan-questioning-of-goog...
~ A.
On 2018-07-18 12:40 pm, Arturo Filastò wrote:
In case you missed here is a letter to Google and Amazon on the blocking of domain fronting by Senator Rubio and Wyden:
https://www.wyden.senate.gov/imo/media/doc/Wyden%20Rubio%20Letter%20to%20Ama...
Press coverage:
https://www.cyberscoop.com/domain-fronting-ban-letter-ron-wyden-marco-rubio-... https://www.accessnow.org/access-now-supports-bipartisan-questioning-of-goog...
~ A.
This is a helpful letter and domain fronting would probably benefit from more public advocacy. The letter did not get much media coverage. There will be lots of reporters at HOPE who may be interested and probably more than one organization that benefits from domain fronting.
Cheers,
Katie
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On Wed, 18 Jul 2018, 18:03 Kate Krauss, ailanthus@riseup.net wrote:
This is a helpful letter and domain fronting would probably benefit from more public advocacy. The letter did not get much media coverage. There will be lots of reporters at HOPE who may be interested and probably more than one organization that benefits from domain fronting.
Hi Kate!
I stand by my criticism as posted at:
https://twitter.com/AlecMuffett/status/1019468247823978496
…in short: that DF is an ugly hack that relies on "SNI" - a feature of SSL which in daily life is leveraged to enable, not bypass, filtering and censorship.
It may be artfully ironic with DF to leverage SNI "for good", but it would probably be wiser to learn to live without either/both, instead encouraging wider adoption of the controversial "TLS 1.3" standard along with the draft "encrypted SNI" feature.
This would be much more in keeping with the Tor ethos of "anonymity loves company".
That any Civil Society organisation is calling for the retention of SNI, is a bit perverse.
-a
On 2018-07-18 6:20 pm, Alec Muffett wrote:
On Wed, 18 Jul 2018, 18:03 Kate Krauss, ailanthus@riseup.net wrote:
This is a helpful letter and domain fronting would probably benefit from more public advocacy. The letter did not get much media coverage. There will be lots of reporters at HOPE who may be interested and probably more than one organization that benefits from domain fronting.
Hi Kate!
I stand by my criticism as posted at:
https://twitter.com/AlecMuffett/status/1019468247823978496
…in short: that DF is an ugly hack that relies on "SNI" - a feature of SSL which in daily life is leveraged to enable, not bypass, filtering and censorship.
It may be artfully ironic with DF to leverage SNI "for good", but it would probably be wiser to learn to live without either/both, instead encouraging wider adoption of the controversial "TLS 1.3" standard along with the draft "encrypted SNI" feature.
This would be much more in keeping with the Tor ethos of "anonymity loves company".
That any Civil Society organisation is calling for the retention of SNI, is a bit perverse.
-a
Hi Alex,
Aha, this is news to me. Could you possibly Explain Like I'm 5: Why is SNI not good, why is TLS 1.3 controversial, and why is it not good to have domain fronting as a tactic we use until we figure out a better one (or preserve it as part of an evolving toolkit)? We could reach a lot of censored users if we had it. I'm assuming this relates to "anonymity loves company" but I don't understand how (literally).
Also, I'm troubled by Google and Amazon's willingness to make a unilateral decision that negatively affects human rights. It is a bad precedent.
Thanks,
Katie
PS: Tor's mission statement, fwiw (it probably supports multiple points of view on DF): "To advance human rights and freedoms by creating and deploying free and open anonymity and privacy technologies, supporting their unrestricted availability and use, and furthering their scientific and popular understanding."
Hello,
For what it's worth, I agree with Alec.
From a technical standpoint, rejecting SNI/Host header mismatches is a perfectly rational thing to do, because it defeats the purpose of having a SNI block in the first place.
From a business standpoint, not wanting to be the conduit for abuse, or jeopardize the rest of their paying customers, who are the involuntary collateral in domain fronting's collateral freedom is also perfectly rational.
On 07/18/2018 11:20 PM, Kate Krauss wrote:
Aha, this is news to me. Could you possibly Explain Like I'm 5: Why is SNI not good, why is TLS 1.3 controversial, and why is it not good to have domain fronting as a tactic we use until we figure out a better one (or preserve it as part of an evolving toolkit)? We could reach a lot of censored users if we had it. I'm assuming this relates to "anonymity loves company" but I don't understand how (literally).
SNI is not good because it is one of, if not the main TLS leaks regarding the intended destination to external observers.
As a gross simplification, the problem SNI exists to solve (when not being intentionally malformed for the purpose of misuse) is thus:
It is common to want lots of separate sites to be hosted behind a common endpoint. For example, a hosting provider may be responsible for "yawning.example", "alec.example", and "kate.example".
The mechanism for doing so is the HTTP `Host` header, which is carried encrypted. (eg: A browser would include `Host: yawning.example` as part of it's request for content.)
Hypothetically, suppose that a hosting provider uses the IP address of 192.0.2.23 to host those three domains. Without SNI, that host has no way of determining which web server a connection is intended to go to without terminating TLS (as the Host header is encrypted) forcing the hosting provider to do something like this:
https://cdn.arstechnica.net/wp-content/uploads/2013/10/GOOGLE-CLOUD-EXPLOITA...
(Image courtesy of the United States National Security Agency)
This precludes each hosted site using their own TLS certificate, and additionally is computationally expensive at the ingress point into hosting provider's network.
The SNI solution to the problem it sets out to solve, is for each TLS connection to include a SNI block that contains the final destination host, un-encrypted in the clear, visible to everybody.
SNI is why, even if you are using TLS, the domain name of the site you are using is visible to the entire world (eg: A SNI block indicates that a otherwise encrypted connection to `kate.example` is destined for `kate.example` rather than `alec.example`).
The benefit of SNI is that, the final destination of the request is visible without doing cryptographic operations (yes, this is the same as the downside). By doing so, there is no need to decrypt anything till the final destination, allowing for greater security/privacy (due to being able to implement true end-to-end encryption, rather than end-to-the-edge-of-their-network encryption) and scalability/performance.
I am of the opinion that as bad as SNI is, not having something like SNI, or SNI being unreliable due to lying clients is far worse.
Also, I'm troubled by Google and Amazon's willingness to make a unilateral decision that negatively affects human rights. It is a bad precedent.
Attempting to compel entities to reverse a perfectly rational technical and business decision with violence (ie: State power) is beyond disturbing.
Regards,
Having an ELI5 is a totally fair request, and I'll do my best; I've had a couple of requests for this already so please pardon me if I take it from the top:
We use encryption to send messages privately from a web-browser (like firefox) to a web-server (like apache) which is running on a computer somewhere in the world; to get this privacy we lock the messages in an "envelope" of encryption, which means that nobody can read the messages unless they have the magic "keys" that are needed to open the envelope.
The problem is: many years ago someone worked out that it's a lot cheaper to have a bunch of web-servers (eg: apache) for websites, on a single computer, and when you have that situation there's a problem: which of the dozens of web-servers is the one which is meant to receive the encrypted message?
You can't reasonably give the same envelope to all of them and see if it works for one; that would be wasteful; so somebody came up with the idea of writing the name of the server (providing a Server Name Indication, or SNI) in cleartext on the front of the envelope.
SNI meant that if there were web servers for Alice.COM, and Bob.ORG on the same machine, then the envelope could be delivered to the machine's address (123 West Street, Boston) and handed directly to Alice or Bob by the machine, for them to decrypt.
Some clever people worked out that they could use this system to get a kind of privacy: if Alice actually *owns* the house, and if Bob is wanted by the police, then people who wanted to mail Bob could write "Alice.COM" in cleartext on the outside of the envelope, and they could encrypt the message *for* Alice, but when the message begins with "Dear Bob,..." then Alice would heave a sigh and hand the message over to Bob to be read. Alice would be acting as a "front" for Bob, and hence "Domain Fronting". The problem with this process is that it stresses Alice and gets stressy, it means that the police can say that Alice is complicit in crime, and also it's less efficient - Alice has to sort through HER mailbox and use HER keys on behalf of Bob. This is bad for Alice.
But also: taking a step back, there's the whole problem of writing names in cleartext on envelopes. Every person in the world who is not in an Alice/Bob kind of relationship, but who wants to use HTTPS, ends up doing the same write-in-cleartext thing to ALL their traffic.
This means that Victoria wants to write a message to PlannedParenthood.COM and has to write the PP.com SNI on the front of *her* envelopes, too; and Victoria's ISP (who is generically against abortion) can just trash those messages entirely ("website not reachable") or can attack them with some sort of man-in-the-middleware.
Ergo: nowadays some clever people at Mozilla, Apple, Cloudflare, etc, have worked out a way that the envelopes still get addressed in cleartext (123 West Street, Boston) but the SNI (Alice.COM, Bob.ORG, PP.COM) is encrypted.
Encrypted SNI means that ISPs cannot editorialise traffic to PP.COM, that Alice no longer has to "front" for Bob and suffer both complexity and moral complicity, and that overall the messages which are passed back and forth to/from all of the above are a LOT less fingerprintable. You might say, "almost anonymous", and that "anonymity loves company". :-)
However, as you'll guess, the security services of the world have been profiting from SNI and from other "features" of older forms of HTTPS, and the idea of losing all this bountiful metadata is painful to them; hence they are fighting tooth-and-nail against the new TLS1.3 - which is so-far largely unfingerprintable / close to anonymous / unmolested by spooks:
https://www.theregister.co.uk/2018/03/23/tls_1_3_approved_ietf/
...and they are looking for division which can be leveraged into "See, even the supposed 'Good Guys' want to keep SNI!".
So, in short: by pursuing Domain Fronting rather than burning it and pursuing Encrypted SNI, we risk advancing the arguments of spooks, and also retarding the adoption of protocols which will provide us all with greater, more secure, more end-to-end (not even Alice-having-to-front-for-...) communication
How does that work?
-a
Posted on Medium.COM as https://medium.com/@alecmuffett/eli5-why-we-should-quietly-stop-domainfronti...
On Thu, Jul 19, 2018 at 12:51 AM, Alec Muffett alec.muffett@gmail.com wrote:
So, in short: by pursuing Domain Fronting rather than burning it and pursuing Encrypted SNI, we risk advancing the arguments of spooks, and also retarding the adoption of protocols which will provide us all with greater, more secure, more end-to-end (not even Alice-having-to-front-for-...) communication
How does that work?
I think it's great that Alec brings up this important issue. But I am wondering:
* When will Encrypted SNI be widely available? My understanding is it will take at least months or years to widely deploy. * We have Domain Fronting now -- is it not reasonable to ask Google and Amazon to keep supporting it until they support ESNI? That's not the same thing as "supporting cleartext SNI forever." * Can't governments or ISPs simply block ESNI requests? Will browsers and CDNs then fall back to cleartext SNI? * While I can see why Google and Amazon might have legitimate business reasons not to permit Domain Fronting, it seems also legitimate to ask them to reconsider in order to support people subjected to censorship. Was legislation or other state coercion hinted at somewhere? In the senators' letter, it says "we respectfully urge you to reconsider."
Arthur
Great and fair questions.
On Thu, 19 Jul 2018 at 16:55, Arthur D. Edelstein arthuredelstein@gmail.com wrote:
- When will Encrypted SNI be widely available? My understanding is it
will take at least months or years to widely deploy.
It will take ages. certainly a few years, to reach ubiquity.
Having lived through the "Hey, here's a great idea, let's put NULL ciphersuites in IPsec to aid Debugging!"-feint by the intelligence community which meant a bunch of people were/are "running VPNs" that were/are essentially cleartext, I am disinclined to approve of any measure, from any direction, which seeks to say "stay, just a little bit longer…" re: Plaintext SNI.
Much better instead to start loudly labelling them as "DEPRECATED, OLD AND BUSTED" right _now_, live with that in the interim, and ease a rapid transition away from the old-and-bustedness as soon as it sediments.
- We have Domain Fronting now -- is it not reasonable to ask Google
and Amazon to keep supporting it until they support ESNI? That's not the same thing as "supporting cleartext SNI forever."
Their infrastructure is migrating away from old and busted, and there is a lot of sense in that migration - Domain Fronting actually has consequences for request security, trust and handling. I could try describing it here, but I would probably mess it up - a much better speaker on this topic is Ryan Sleevi.
- Can't governments or ISPs simply block ESNI requests? Will browsers
and CDNs then fall back to cleartext SNI?
Great questions; the first attempts at rolling out TLS1.3 (and subsequent embarrassing reversal) provide a guide to the all-or-nothing breakage:
https://searchsecurity.techtarget.com/news/450413934/Chrome-backs-out-of-TLS...
Short version: getting the pain over-with quickly and then pursuing a rapid transition, seems to be the best strategy; if we push for Google to retain PlainSNI and DF, and if we are successful, then we are leaving the field open to a Post-TLS1.3-Deployment "slippery-slope" argument against adopting Encrypted SNI.
Better, instead, to ram them through, together, in lockstep.
* While I can see why Google and Amazon might have legitimate business
reasons not to permit Domain Fronting, it seems also legitimate to ask them to reconsider in order to support people subjected to censorship.
Ask all you like, but it's a bad idea; you're basically asking them to risk all their traffic on behalf of (for example) Tor. Better, instead, to fix the shitty software, so they can say "We have Tor Relays running on our Infra? Well, they're just another customer, nothing we can do about it!" - rather than face accusations of having implemented DF and bending their own security models to support the democratic peccadilloes of the liberal west.
Was legislation or other state coercion hinted at somewhere? In the senators' letter, it says "we respectfully urge you to reconsider."
I can't speak to that, but I have trusted sources who tell me that GCHQ was recently trawling the Financial Services companies (ie: investment banks and so forth) in the "City" of London (ie: financial district) looking for big names that they could parade at the recent IETF meeting in London, to try and add leverage to drilling some surveillance-friendly holes into the TLS specification. They were looking for big names who would go on record to say "We require man-in-the-middle-capabilities in order to maintain legal compliance" - which is bullshit for any decently run organisation. To a first approximation, nobody came forwards to support their perspective.
If you want to read GCHQ's perspective on how stronger, better security in TLS1.3 makes things "harder for enterprise", read this blog post: https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterpris...
Speaking as a former Enterprise Security Architect for Sun Microsystems, and having build systems for banks, I consider the blogpost to be an utter fabrication, unworthy of respect.
As such, I might perhaps be a little oversensitive, but I am deeply suspicious of any proposition from any quarter which essentially attempts to sediment old-and-busted TLS1.2 functionality.
- alec
Just wanted to say that this thread has been very informative and super approachable for someone with a poor understanding of encryption. Really appreciate it!
best, -Richard
On 07/19/2018 10:34 AM, Alec Muffett wrote:
Great and fair questions.
On Thu, 19 Jul 2018 at 16:55, Arthur D. Edelstein <arthuredelstein@gmail.com mailto:arthuredelstein@gmail.com> wrote:
* When will Encrypted SNI be widely available? My understanding is it will take at least months or years to widely deploy.
It will take ages. certainly a few years, to reach ubiquity.
Having lived through the "Hey, here's a great idea, let's put NULL ciphersuites in IPsec to aid Debugging!"-feint by the intelligence community which meant a bunch of people were/are "running VPNs" that were/are essentially cleartext, I am disinclined to approve of any measure, from any direction, which seeks to say "stay, just a little bit longer…" re: Plaintext SNI.
Much better instead to start loudly labelling them as "DEPRECATED, OLD AND BUSTED" right _now_, live with that in the interim, and ease a rapid transition away from the old-and-bustedness as soon as it sediments.
* We have Domain Fronting now -- is it not reasonable to ask Google and Amazon to keep supporting it until they support ESNI? That's not the same thing as "supporting cleartext SNI forever."
Their infrastructure is migrating away from old and busted, and there is a lot of sense in that migration - Domain Fronting actually has consequences for request security, trust and handling. I could try describing it here, but I would probably mess it up - a much better speaker on this topic is Ryan Sleevi.
* Can't governments or ISPs simply block ESNI requests? Will browsers and CDNs then fall back to cleartext SNI?
Great questions; the first attempts at rolling out TLS1.3 (and subsequent embarrassing reversal) provide a guide to the all-or-nothing breakage:
https://searchsecurity.techtarget.com/news/450413934/Chrome-backs-out-of-TLS...
Short version: getting the pain over-with quickly and then pursuing a rapid transition, seems to be the best strategy; if we push for Google to retain PlainSNI and DF, and if we are successful, then we are leaving the field open to a Post-TLS1.3-Deployment "slippery-slope" argument against adopting Encrypted SNI.
Better, instead, to ram them through, together, in lockstep.
* While I can see why Google and Amazon might have legitimate business reasons not to permit Domain Fronting, it seems also legitimate to ask them to reconsider in order to support people subjected to censorship.
Ask all you like, but it's a bad idea; you're basically asking them to risk all their traffic on behalf of (for example) Tor. Better, instead, to fix the shitty software, so they can say "We have Tor Relays running on our Infra? Well, they're just another customer, nothing we can do about it!" - rather than face accusations of having implemented DF and bending their own security models to support the democratic peccadilloes of the liberal west.
Was legislation or other state coercion hinted at somewhere? In the senators' letter, it says "we respectfully urge you to reconsider."
I can't speak to that, but I have trusted sources who tell me that GCHQ was recently trawling the Financial Services companies (ie: investment banks and so forth) in the "City" of London (ie: financial district) looking for big names that they could parade at the recent IETF meeting in London, to try and add leverage to drilling some surveillance-friendly holes into the TLS specification. They were looking for big names who would go on record to say "We require man-in-the-middle-capabilities in order to maintain legal compliance" - which is bullshit for any decently run organisation. To a first approximation, nobody came forwards to support their perspective.
If you want to read GCHQ's perspective on how stronger, better security in TLS1.3 makes things "harder for enterprise", read this blog post: https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterpris...
Speaking as a former Enterprise Security Architect for Sun Microsystems, and having build systems for banks, I consider the blogpost to be an utter fabrication, unworthy of respect.
As such, I might perhaps be a little oversensitive, but I am deeply suspicious of any proposition from any quarter which essentially attempts to sediment old-and-busted TLS1.2 functionality.
- alec
-- http://dropsafe.crypticide.com/aboutalecm
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On 2018-07-19 3:51 am, Alec Muffett wrote:
So, in short: by pursuing Domain Fronting rather than burning it and pursuing Encrypted SNI, we risk advancing the arguments of spooks, and also retarding the adoption of protocols which will provide us all with greater, more secure, more end-to-end (not even Alice-having-to-front-for-...) communication
How does that work?
-a
Thank you! I'm extremely grateful to both Alec and Yawning for these thoughtful and clear explanations. So there can be no possible domain fronting under TSL 1.3? That door is closed unless we try to preserve it, maybe for a few months. However, Alec points out that that might send a bad signal. But! Is TSL 1.3 inevitable now that it's been approved by IETF? If so, does it make sense to push for domain fronting as a transitional strategy until we have a better plan? One can help to clarify potentially bad signals by talking to reporters, putting out blog posts, tweeting, asking allies to put out communications, etc.
I was really interested in Yawning's comment about state power, which I hadn't thought of. I see several different actors, then: The NSA, which represents massive state power, and opposes TSL 1.3--that post-it, which I'd forgotten about, was haunting.
Then there is the letter by Wyden, which I see mostly as a PR tool. Wyden is not proposing a bill in Congress; he uses publicity here to get attention to the issue in the service of human rights. His tech advisor Chris Soghoian may support the letter. This doesn't feel like an abuse of power to me (I respect that it does to Yawning)--for instance, even Tor could put out a well-written and publicized letter and probably get *more* attention to the issue than Wyden's letter did (I'm not suggesting that we should).
But there is other state power--the quiet state power of China and other censoring countries. There are billions of people without access to uncensored Internet. This affects their safety and their everyday decisionmaking and their personal agency. Nothing they have offers the security of Tor.
So my final question--and this may just be contained in a link someone could just post, but better, ELI5 here (if appropriate)--is what might work, what is on the horizon, does it need more support, and if so, how can we support it?
Thanks again Alec and Yawning,
Katie
On Thu, 19 Jul 2018 at 18:54, Kate Krauss ailanthus@riseup.net wrote:
On 2018-07-19 3:51 am, Alec Muffett wrote:
Thank you! I'm extremely grateful to both Alec and Yawning for these thoughtful and clear explanations. So there can be no possible domain fronting under TSL 1.3?
Not quite.
DomainFronting essentially means that "SNI Says Alice, First Line Of Letter Says 'Dear Bob'".
You can do that in both TLS1.2 and 1.3, with Plaintext SNI or (in 1.3) with Encrypted SNI.
However:
a) doing it is a pain in the ass for the service provider, irrespective of what version TLS is in use, plus it has negative security consequences (see previous email from me)
b) if we make TLS1.3+EncryptedSNI into a ubiquitous offering, the need for DF becomes moot. It becomes pointless.
Is TSL 1.3 inevitable now that it's been
approved by IETF?
Kinda, but we need to watch carefully for people trying to drill holes in it, and/or for "adding friction" to anyone wanting to _leave_ TLS1.2
Such friction includes the Civil Society community screaming "Waaaaah! But losing DF harms Tor!"
Honest answer: "short term, yes; long term we can win hugely, and we piss off the NSA too!".
If so, does it make sense to push for domain fronting as a transitional strategy until we have a better plan?
Exactly. Clearly deprecate it, limp along with what DF we can get, and push hard to get TLS1.3+ESNI into the world's default webserver configs as soon as possible, and I think we'll be shooting the right direction.
His tech advisor
Chris Soghoian may support the letter.
I've seen Chris' work before, eg: in support of export control of security software ("Wassenaar") to stop the outflow of spyware from Western countries to at-risk countries like Ethiopia.
I won't argue with his sentiment, then as now, but I feel (if he's also behind this) that his approaches lack adequate consideration of bigger pictures and long-term goals.
So my final question--and this may just be contained in a link someone could just post, but better, ELI5 here (if appropriate)--is what might work, what is on the horizon, does it need more support, and if so, how can we support it?
We must boldly and clearly recognise DF as the ugly kludge that it is, and make sure the world knows that; I feel that Tor should (if resources can be found) get involved with the community of people and companies who are pursuing solid communications security at the HTTPS layer; in some senses they are only trying to emulate the goals which Tor has had for years (decades?) and there must be experience worth sharing.
-a
On Thu, Jul 19, 2018 at 08:51:13AM +0100, Alec Muffett wrote:
Ergo: nowadays some clever people at Mozilla, Apple, Cloudflare, etc, have worked out a way that the envelopes still get addressed in cleartext (123 West Street, Boston) but the SNI (Alice.COM, Bob.ORG, PP.COM) is encrypted.
Encrypted SNI means that ISPs cannot editorialise traffic to PP.COM, that Alice no longer has to "front" for Bob and suffer both complexity and moral complicity, and that overall the messages which are passed back and forth to/from all of the above are a LOT less fingerprintable. You might say, "almost anonymous", and that "anonymity loves company". :-)
So to be clear, with encrypted SNI you could get the same benefits of domain fronting by simply renting hosting where one IP is used for multiple different services, in exactly the same way that domain fronting is done today?
Or am I missing something?
On Sat, 21 Jul 2018, 00:01 Peter Todd, pete@petertodd.org wrote:
So to be clear, with encrypted SNI you could get the same benefits of domain fronting by simply renting hosting where one IP is used for multiple different services, in exactly the same way that domain fronting is done today?
Yes. You could hide amongst the herd with zero magical bullshit being required, on the proviso that ESNI becomes approximately normal, first.
Hence the importance of getting behind it and pushing it as a standard part of eventual TLS1.3 migrations, rather than have it arrive AFTER the initial major 1.3 migrations and thereby requiring further effort to make it normal.
Otherwise it's like someone bringing out the ketchup after you have already finished eating your hot dog.
-a
On Sat, Jul 21, 2018 at 11:57:59AM +0100, Alec Muffett wrote:
On Sat, 21 Jul 2018, 00:01 Peter Todd, pete@petertodd.org wrote:
So to be clear, with encrypted SNI you could get the same benefits of domain fronting by simply renting hosting where one IP is used for multiple different services, in exactly the same way that domain fronting is done today?
Yes. You could hide amongst the herd with zero magical bullshit being required, on the proviso that ESNI becomes approximately normal, first.
Hence the importance of getting behind it and pushing it as a standard part of eventual TLS1.3 migrations, rather than have it arrive AFTER the initial major 1.3 migrations and thereby requiring further effort to make it normal.
Otherwise it's like someone bringing out the ketchup after you have already finished eating your hot dog.
Thanks! That clears things up for me; hopefully we get ESNI deployed widely.
tor-project@lists.torproject.org