
DNS Over TLS: Encrypting DNS End-To-end - jgrahamc
https://code.fb.com/security/dns-over-tls/
======
amaccuish
FYI this is about the connection from a resolver to the authoritive name
server, not the connection between a client and a resolver.

~~~
move-on-by
Thank you for this clarification. Its definitely an interesting decision. I
wouldn't think there is much to gain privacy-wise between cloudflare and FB's
DNS servers.

Without a doubt, as far as security goes, DNSSEC would provide the security
side - with DoT being a privacy provider. However, FB doesn't implement
DNSSEC. I know there is a LOT of opinions on DNSSEC and I completely
understand why they do not implement it. This just leaves me in the dark a bit
as to why they did this. Anyone have insights?

~~~
ilovecaching
> I wouldn't think there is much to gain privacy-wise between cloudflare and
> FB's DNS servers.

You gain everything by this. Encrypting traffic from your stub resolver to the
recursive resolver is meaningless if the recursive is going to send your
request unencrypted to the authoritative. Recursive resolvers will send ECS
data revealing your subnet and fingerprinting information, and open you up to
active and passive mitm attacks.

> Without a doubt, as far as security goes, DNSSEC would provide the security
> side

You're comparing apple to oranges here, and DNSSEC is a far cry from total
security. They are complementary; DoT provides a private and protected path to
the authoritative, while DNSSEC proves origin authenticity and response
correctness. But you're right in that DNSSEC is controversial and difficult to
turn on.

~~~
vavrusa
From operational perspective, it may be easier to maintain a certificate
(after all, that's what you already do for an HTTPS service) than a DNSSEC
signed zone. It is also easier if you have a multiple DNS providers, since you
don't have to coordinate zone resigning. On the other hand, DoT doesn't
provide the same properties (like client-side revalidation) as record level
DNSSEC. It is undoubtedly an imperfect solution, but better than a perfect
solution that isn't deployed. I see the two technologies as complementary, a
fairly good DNSSEC deployment at the TLD level can provide a safe way for key
discovery at SLD level. There are many facets to this, and it is still fairly
early in resolver-to-authoritative DoT standardization process, this is just
one of the first steps to show that it's feasible in real world.

------
xte
I trust more my ISP, witch is in my country, under my country laws that remote
DNS under unknown laws, operate by super-big corps or by unknown guys...

It's the same for VPNs: today to many people ask to "VPNs" without considering
who host them on the other side and many other "encryption manias".

Conceptually I fear far more modern browsers+webapps tracing capabilities than
DNS-based monitoring so for me that's nice but certainly non important. Sorry
for being rude.

~~~
move-on-by
The connection discussed in this post is between FB’s DNS servers and
CloudFlare- not end users. So ISP trust and VPN usage is a moot point here

------
ilovecaching
This is absolutely wonderful. DNS has long been an easy target for attackers,
and its design has been nothing but painful to retrofit with better security
mechanisms the have led to incredibly low adoption (I'm looking at you DNSSEC)
of better protections against forgery.

Worse still, clients that believe themselves secure using HTTPS are
essentially voiding their warranty by using UDP DNS. DNSCrypt, DoH, and DoT
will hopefully change all of this, and I think it says something about
Facebook that they're working with Cloudflare to protect their users from the
dangers of DNS. Nicely done CF and FB.

~~~
petronio
"Worse still, clients that believe themselves secure using HTTPS are
essentially voiding their warranty by using UDP DNS."

I wouldn't go that far. It's true that if the browser has never gone to a
website before you can MITM to have the client connect to a server that
doesn't support SSL and basically be left with a MITM'd HTTP connection. It's
not fool-proof, but there's various measures that are being deployed to reduce
such attacks:

* Chrome has started adding "Not Secure" to proactively alert users of websites not using SSL. If a user sees a major website and "Not Secure" is visibly displayed, hopefully that'll serve as a good warning to not continue.

* HSTS won't protect the initial connection, but will protect from future downgrade attacks by telling the browser to not accept insecure connections from the domain.

* Unless it has been otherwise tampered with, the HTTPS connection will still be encrypted and the certificate verified regardless of whether DNS has been tampered with. At that point the attacker would need a valid certificate from a trusted CA for the domain, which is outside of most threat models and they could likely get a certificate to MITM the DNS over TLS requests as well.

* In more secure settings, applications can be forced to only accept specific CAs, oftentimes a self-generated one. The above attack wouldn't work in that occasion.

Generally speaking, the biggest gains in DNS over TLS come in privacy, not
security (although there are some, especially for applications that don't
enforce SSL).

~~~
newscracker
_> HSTS won't protect the initial connection, but will protect from future
downgrade attacks by telling the browser to not accept insecure connections
from the domain._

But HSTS preload [1] is meant to protect even the initial connection, right?
If a site serves HSTS headers, it could (potentially) choose to be added to
the preload list that’s used by many browsers.

[1]: [https://hstspreload.org](https://hstspreload.org)

~~~
petronio
I hadn't heard of that service before, very interesting, thanks for pointing
it out.

------
ubittibu
Sorry for my ignorance, but didn’t we have Stubby ad the latest DNSCrypt for
the same purpose? In what is this project different?

------
Avamander
I'd rather want to see DNS-over-QUIC

~~~
skrause
I don't understand the downvotes. Wouldn't QUIC be the perfect fit for a
secure transport of DNS requests? The IETF already has a draft:
[https://tools.ietf.org/html/draft-huitema-quic-
dnsoquic-05](https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-05)

------
badrabbit
Can a TLS connection ever be considered end-to-end secure? I mean,it's
perfectly acceptable for a middleware with a valid cert from an authorized CA
to intercept the traffic before the true endpoint,not to mention loadbalancers
and other possible TLS terminators.

As I understand it,end-to-end means application to application (endpoint to
endpoint?) with assurance to the client that no middleware can intercept
traffic successfully. Always thought TLS only assured the presenter of the
ServerCertificate is authenticated for the subject,that is to say the client
cannot say "I am sure this is the server I meant to communicate with",it can
only say "The server I'm speaking with has authority to communicate on behalf
of my intended peer"

~~~
move-on-by
> perfectly acceptable for a middleware with a valid cert from an authorized
> CA to intercept the traffic

Wow, that is a LOT easier said then done. With today’s Certificate
Transparency Log requirements, any new certificate must have a
cryptographically verifiable entry into at least two different public logs. If
a bad actor at a CA were to generate this trusted cert you described, there
would have to be a public record of it for it to be trusted. Beyond that, if
the CA was found to be complicit, then they would lose their trusted status-
looking at you Symantec.

~~~
badrabbit
If they own the device they can install trusted root CAs that are not public
or have CT logs. Anyway,question is if you can call TLS end to end or not.

~~~
move-on-by
Yes, if you own the device, you can choose what to trust beyond valid cert
requirements. To answer your question, yes, I do consider TLS end-to-end
despite involvement of a 3rd party. I believe certificate transparency has
removed a lot of the trust issues around CAs that previously existed. Trust is
no longer required when there is public verifiable logs. Also, with the trend
moving towards short cert lifespans, the risk of certs being stolen and used
against you is more difficult- requiring regular updates. I hope to see the
max cert validity periods become shorter and shorter

~~~
badrabbit
That's ridiculous. The popular CAs are not part of the TLS standard and
neither is CT. Plenty of intranet TLS with intetnal CAs. CTs are good if the
end client only uses root CAs that participate.

Let's say CT solves the server authentication issues,how does does the server
authenticate the client? End to end means both parties authenticate,TLS
supports client authnetication but a) DNS over HTTPs isn't doing that b) even
if it did there isn't CT for client certs...

