3 ms·

Since you need DNS to get the IP address in the first place, it's already true that ESNI is nearly useless without encrypted DNS.

by shawnz 6y ago

LinuxBender 6y ago
True. I guess I assumed incorrectly that the original design of ESNI would not require DNS be in the flow for the validation, meaning that if I had local DNS, or /etc/hosts entries, then nobody would see the name. But if special record types are required, then /etc/hosts or local DNS won't suffice. Just my opinion, but it feels like this was made unnecessarily complicated. Feels like some concepts from SSH (host keys, caching host keys) and web servers (default _server_ name) could have been used for this, since I don't really need to validate who I am talking to for passing the name.
- shawnz 6y ago
  Hopefully, browsers and operating systems will add capacities to store the records locally. They allude that this could be possible in the spec. > This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to [HTTPS-RR], though other delivery mechanisms are possible.
- londons_explore 6y ago
  > since I don't really need to validate who I am talking to for passing the name. If you don't validate who you're talking to, some ISP will run a MITM attack simply to log accessed hostnames (even if they can't MITM the final TLS connection)
  - LinuxBender 6y ago
    True, but this would be pretty easy to spot. I am ok with the compromise of using the same method used with ssh host keys for passing the name. The browser can cache these keys and tell the person if things are changing. At least that would be much simpler than these additional DNS lookups and assuming people are using encrypted DNS to a trusted DNS provider, but that is a whole other discussion.
    - shawnz 6y ago
      The concern is working around state level or ISP level censorship and monitoring of domain names. TLS already allows you to detect tampering without ESNI so that's not a goal here
thayne 6y ago
Unless the DNS is also encrypted. In fact, the firefox implementation for ESNI, and I assume now for ECH, required DNS over HTTPS to be enabled in firefox for ESNI to work. That means that if ESNI is used the domain is never transmitted in plaintext. However, it has the signfificant downside that if you can't or don't want to use Firefox's DoH, and your system DNS is already encrypted (DoH, DoT, VPN, etc.), then you can't get ESNI. See https://bugzilla.mozilla.org/show_bug.cgi?id=1500289 https://bugzilla.mozilla.org/show_bug.cgi?id=1500289

Since you need DNS to get the IP address in the first place, it's already true that ESNI is nearly useless without encrypted DNS.

by shawnz 6y ago

Since you need DNS to get the IP address in the first place, it's already true that ESNI is nearly useless without encrypted DNS.

LinuxBender 6y ago

True. I guess I assumed incorrectly that the original design of ESNI would not require DNS be in the flow for the validation, meaning that if I had local DNS, or /etc/hosts entries, then nobody would see the name. But if special record types are required, then /etc/hosts or local DNS won't suffice. Just my opinion, but it feels like this was made unnecessarily complicated. Feels like some concepts from SSH (host keys, caching host keys) and web servers (default _server_ name) could have been used for this, since I don't really need to validate who I am talking to for passing the name.

shawnz 6y ago
Hopefully, browsers and operating systems will add capacities to store the records locally. They allude that this could be possible in the spec. > This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to [HTTPS-RR], though other delivery mechanisms are possible.
londons_explore 6y ago
> since I don't really need to validate who I am talking to for passing the name. If you don't validate who you're talking to, some ISP will run a MITM attack simply to log accessed hostnames (even if they can't MITM the final TLS connection)
- LinuxBender 6y ago
  True, but this would be pretty easy to spot. I am ok with the compromise of using the same method used with ssh host keys for passing the name. The browser can cache these keys and tell the person if things are changing. At least that would be much simpler than these additional DNS lookups and assuming people are using encrypted DNS to a trusted DNS provider, but that is a whole other discussion.
  - shawnz 6y ago
    The concern is working around state level or ISP level censorship and monitoring of domain names. TLS already allows you to detect tampering without ESNI so that's not a goal here

thayne 6y ago

Unless the DNS is also encrypted. In fact, the firefox implementation for ESNI, and I assume now for ECH, required DNS over HTTPS to be enabled in firefox for ESNI to work. That means that if ESNI is used the domain is never transmitted in plaintext. However, it has the signfificant downside that if you can't or don't want to use Firefox's DoH, and your system DNS is already encrypted (DoH, DoT, VPN, etc.), then you can't get ESNI. See https://bugzilla.mozilla.org/show_bug.cgi?id=1500289 https://bugzilla.mozilla.org/show_bug.cgi?id=1500289