On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:
>
> I just submitted:
>
> https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> This draft describes a DNS-based approach to doing encrypted SNI.
>
> Previously, we had thought this wouldn't work because only sites that
> were particularly vulnerable would do it, and so the use of ESNI marks
> you out. The idea behind this draft is that there are a lot of sites
> which are hosted by -- and whose DNS is run by -- a large provider,
> and that provider can shift many if not all of its sites to ESNI at
> once, thus removing the "standing out" issue and making a DNS-based
> approach practical.
The recent Russia versus Telegram episode is kinda worrisome in this
regard. Basically, it looked like the actions that created massive
collaterial damage got at least two very large cloud provoders to
disable one technique of hiding the name of the target server.
> I am working on an implementation for NSS/Firefox and I know some
> others are working on their own implementations, so hopefully we can
> do some interop in Montreal.
>
> This is at a pretty early stage, so comments, questions, defect
> reports welcome.
One thing I noticed: First there is this in evaluation:
7.2.4. Do not stick out
By sending SNI and ESNI values (with illegitimate digests), or by
sending legitimate ESNI values for and "fake" SNI values, clients do
not display clear signals of ESNI intent to passive eavesdroppers.
Is that suggesting to send fake ESNI values? If so, there is this in
endpoint behavior:
5.2. Client-Facing Server Behavior
o If the EncryptedSNI.record_digest value does not match the
cryptographic hash of any known ENSIKeys structure, it MUST abort
the connection with an "illegal_parameter" alert. This is
necessary to prevent downgrade attacks.
So sending out fake ESNI values seems unsafe. My reading of that is
that if server supports ESNI, but is not configured, then it MUST
terminate (illegal_parameter) any handshake where ESNI extension
was offered in. But that behaviour would cause any split mode
handshakes to fail if backend supports ESNI.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
