Issues
--
* tlswg/draft-ietf-tls-esni (+2/-0/💬0)
2 issues created:
- Nonce rationale clarity (by bemasc)
https://github.com/tlswg/draft-ietf-tls-esni/issues/253
- Avoid padding cliff (by bemasc)
https://github.com/tlswg/draft-ietf-tls-esni/issues/252
Pull requests
---
On Thu, Jul 30, 2020 at 11:16:50AM -0700, Christian Huitema wrote:
> Thanks for the report. I think this relates to our ambivalence about the
> requirement for ESNI to not "stick out". That requirement is hard to
> meet, and designs have drifted towards an acceptation that it is OK to
> stick out a
I’m pretty sure your reasoning is wrong. In the ideal world, if *everybody*
enabled ESNI - then *maybe* the GFW would relent.
The way things are - is not smart pretending reality is not what it is.
Using your terminology - better blend with the crowd, because you aren’t likely
to live long en
I just want to remind you about my FakeSNI draft
https://tools.ietf.org/html/draft-belyavskiy-fakesni-02
The idea behind it was cheating the solutions less sophisticated than GFW.
Yes, in real life it will require deep cooperation between DNS and hosting
and yes, the resource still can be blocked
>From the writeups I've seen, what they're blocking is TLS 1.3, not ESNI.
Since ESNI can be de-anonymised with a high degree of success (see various
conference papers on this) and in any case doesn't matter for the most
frequently-blocked sites like Facebook, Instagram, Twitter, etc, it may not
eve
On 8/9/2020 8:31 PM, Peter Gutmann wrote:
> >From the writeups I've seen, what they're blocking is TLS 1.3, not ESNI.
> Since ESNI can be de-anonymised with a high degree of success (see various
> conference papers on this) and in any case doesn't matter for the most
> frequently-blocked sites li
