1542754 - eSNI on Android 9 (using DoT from android)

Status: RESOLVED DUPLICATE of bug 1500289

(Core :: Networking: DNS, enhancement, P3)

Description

[val.zapod.vz]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

Steps to reproduce:

If you put 1dot1dot1dot1.cloudflare-dns.com in Private DNS in Android 9, DNS over TLS will be activated and working. But your Trusted Recursive Resolver doesn't consider it, it still should be activated to access network.security.esni.enabled set to true.

Actual results:

Trusted Recursive Resolver should be activated though the user may already have DoH or DoT installed. Also I don't understand why DNS should be encrypted. All that happens in encryption of SNI in DNS part is asking public key from TXT of _esni. subdomain of the domain you accessing; I understand the risk of DPI finding out _esni DNS query, but on the other hand, DPI will not intervenue with TLS 1.3 eSNI connection itself, it will be very helpfull in countries, which has such DPI regulation; besides that DNS queries are cached, so it means that even if DPI will block access the first time, the second time it should work.

Expected results:

network.security.esni.enabled should not be connected with TRR in any way, after that I think we should rewrite its defaults to true. Look into it; make sure that if any problems to connection happen, it would go down to non encrypted SNI. But true should be the defaults.

Besides that I think we should help Google to implement it. After all I think the idea of eSNI has the same level of revolution as ephemeral keys of perfect forward secrecy in https. After that DNSSEC keys can be used as certificates insteed of CA certificates. I am not talking about only IP blocks possible after eSNI will become popular. Post DPI era is coming!

Look into https://bugs.chromium.org/p/chromium/issues/detail?id=908132

Comment 1

[uBlock-user]

There's already an enhancement request for ESNI to work without DoH on OS level -- https://bugzilla.mozilla.org/show_bug.cgi?id=1500289

Comment 2

[Junior [inactive]]

Could you triage this one, Valentin?
Thanks.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

So, doing ESNI depends on being able to resolve TXT records.
Due to the fact that the ability to do this varies greatly from platform to platform, Firefox only supports it via DoH, which is platform independent.

For future reference, there are some APIs we might use:

On Android
https://developer.android.com/reference/android/net/nsd/NsdServiceInfo.html#getAttributes()

On Linux
https://stackoverflow.com/questions/2315504/best-way-to-resolve-a-dns-txt-record-on-linux-unix-posix-bsd-type-systems

I couldn't find a solution for windows, but suggestions are welcome.

In any case, this isn't high priority. I don't see it being fixed too soon unless someone volunteers a patch.

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Removing this part from the title, since DNS over TLS is encrypted DNS.

Comment 5

[val.zapod.vz]

Maybe it is better to consentrate on Android only. Because I can't find implementation for IN TXT in windows, I suppose you should write your own resolver))

Comment 6

[nusenu]

(In reply to Valentin Gosu [:valentin] from comment #3)

So, doing ESNI depends on being able to resolve TXT records.

FYI: In the latest version of the I-D (-03 from 2019-03-11) TXT records have been replaced with a new RR type (ESNIKeys),
TXT records are no longer used.
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1

Comment 7

[val.zapod.vz]

(In reply to nusenu from comment #6)

Very interesting, but I suppose you are mistaken
'IANA is requested to create an entry, ESNI(0xff9f), in the existing
registry for Resource Record (RR) TYPEs (defined in [RFC6895]) with
"Meaning" column value being set to "Encrypted SNI".'

So not ESNIkeys, but just ESNI, also 0xff9f is 65439, so it is reserved for private use.
(65280-65534) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

Comment 8

[Valentin Gosu [:valentin] (he/him)]

(In reply to nusenu from comment #6)

(In reply to Valentin Gosu [:valentin] from comment #3)

So, doing ESNI depends on being able to resolve TXT records.

FYI: In the latest version of the I-D (-03 from 2019-03-11) TXT records have been replaced with a new RR type (ESNIKeys),
TXT records are no longer used.
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1

The argument still stands. Getting other record types from system APIs is even more difficult.

Comment 10

[val.zapod.vz]

(In reply to PTO until September 9th from comment #8)

The argument still stands. Getting other record types from system APIs is even more difficult.

Yeah, look there, I asked chromium devs about which (ESNI or TXT) they are going to use. And they will use ESNI. https://bugs.chromium.org/p/boringssl/issues/detail?id=275#c_ts1561592153

Are you in contact with cloudflare? What are they going to do?

Comment 11

[val.zapod.vz]

How do I turn ECH/eDNI in new Android Firefox? about:config does not work.

Comment 12

[Valentin Gosu [:valentin] (he/him)]

(In reply to val.zapod.vz from comment #11)

How do I turn ECH/eDNI in new Android Firefox? about:config does not work.

ECH is not yet supported - the implementation should be finalized later in the autumn.
Only the old TXT record ESNI is supported and it can be enabled by setting following prefs: network.trr.mode to 2 or 3 and network.security.esni.enabled to true. Note that ESNI is known to have some bugs that prevent some pages from loading, and has never been tested on Android.

Comment 13

[val.zapod.vz]

is not yet supported - the implementation should be finalized later in the autumn.
It was working perfectly untill you made a redesign and broke about:config. Redesign from today.

Comment 14

[Valentin Gosu [:valentin] (he/him)]

(In reply to val.zapod.vz from comment #13)

is not yet supported - the implementation should be finalized later in the autumn.
It was working perfectly untill you made a redesign and broke about:config. Redesign from today.

The ESNI spec is not finalized. The implementation was based on the now-expired draft: https://www.ietf.org/archive/id/draft-rescorla-tls-esni-00.txt which used TXT records.
The new one is at: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ and we're currently working to implement it in bug 1652677.
It also depends on interop with the server software that supports it.

Comment 15

[val.zapod.vz]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #12)

(In reply to val.zapod.vz from comment #11)

How do I turn ECH/eDNI in new Android Firefox? about:config does not work.

ECH is not yet supported - the implementation should be finalized later in the autumn.
Only the old TXT record ESNI is supported and it can be enabled by setting following prefs: network.trr.mode to 2 or 3 and network.security.esni.enabled to true. Note that ESNI is known to have some bugs that prevent some pages from loading, and has never been tested on Android.

Okay, I found the fix, about:config does not work in Firefox Stable, but works in Firefox nighty. There you can turn on eSNI and trr and get rid of government censorship, lol. Here is the bug. Why you do not know that, Valentin? :confused https://github.com/mozilla-mobile/fenix/issues/7865

Comment 16

[Valentin Gosu [:valentin] (he/him)]

This bug is about platform support for the feature (using DoT). Please take any other requests to the github issue. Or if you encounter any problem please file another bug. Thanks!