On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon <mel...@fugue.com> wrote: > Marek, forgive me for being blunt, but your reply was completely > non-responsive. DoH and DoT are being used because they address a threat > model, or because, as Bert rather bluntly put it, they allow content > providers to study our query stream. They are not being used "because they > are standards track documents." If you don't have any reason other than > that to use DoH or DoT, then you shouldn't use them.
No worries, I hoped I described the use case, but perhaps not well enough. > You say that your proposal does not impact DoT's ability to address the > threat model or use case that is the reason it is being used. But this is > doesn't make sense to me. The trust model for DoT and DoH right now is > that they are configured by the user for the user's reasons, or by the > service provider for the service provider's reasons. You are proposing This is the issue that the draft is trying to solve. The service provider doesn't have a way to configure DoT on the stub resolver. This problem is described in https://tools.ietf.org/html/rfc8310#section-6.7 What I'm trying to address more specifically is https://tools.ietf.org/html/rfc8310#section-7.3 > that whatever configuration the user or service provider has set up be > replaced by information received by DHCP, and that "DHCP authentication", > which doesn't exist, be used to validate this information. This is a The "DHCP authentication" does exist, I believe you're referring the deployment status. I'm happy if we say the draft must depend on RFC3315, or discuss the trustworthiness of the responses, but surely there must be a way forward if we want to keep the recursive DNS (last mile) decentralized and free from tampering. > completely different trust model than the current trust model. Maybe it's > a good idea, maybe it's a bad idea, but it's completely different. So you > need to figure out the existing trust model and figure out how your proposal > impacts that trust model. To define a DHCP option before you've done this > is putting the cart before the horse. I described one possible way how clients could interpret the advertised information using a trusted CA bundle. At the very least, if my ISP or office network advertises resolvers on port 853, using those is arguably better than the same resolver on port 53. > On Sat, Aug 18, 2018 at 5:58 PM, Marek Vavruša <mvavr...@cloudflare.com> > wrote: >> >> Hi Ted, >> >> thanks for comments. As said, the draft doesn't try to change the >> trust model or fix DHCP authentication, it merely offers network >> operators the ability to advertise secure resolvers for their network. >> The added "danger" is that recipient inherently trusts the >> information. >> >> On Sat, Aug 18, 2018 at 2:22 PM, Ted Lemon <mel...@fugue.com> wrote: >> > DHCP authentication doesn't exist. We already rejected a draft that >> > described how to set up DoH with DHCP. Yours is a little more >> > complicated, >> > but doesn't seem any less dangerous. Before you go any farther on >> > this, >> > you might ask yourself a couple of questions: >> > >> > 1. Why is DoH being used? >> >> The DoT and DoH are being used because they're both either standard or >> on a standards track and have deployed client software. >> >> > 2. What is the thread model that DoH is addressing? >> > 3 How does adding this configuration mechanism impact DoH's ability to >> > address that threat model? >> >> It does not. In both cases, determining whether the resolver (or its >> capabilities) provided by a DHCP server can be trusted is up to the >> client. >> The current model is that either OS or applications like browsers >> install a curated CA bundle with CA's the client should trust. >> When a DNS stub resolver receives a request, it looks into the >> resolv.conf (simplifed) and picks a resolver to send query to. >> Currently the most common method is to pick first, but it might prefer >> resolvers with secure capabilities first. >> If a resolver is advertised as secure, the stub resolver may do a TLS >> handshake and check the certificate. >> Now at this step, it may: >> >> a) only trust certificates issued by a CA trusted by the application >> with the resolver IP address in SAN (trust system configuration) >> b) ditto, but certificates with advertised ADN in SAN or matching >> SPKI pin (this presumes the client trusts DHCP offering, or is okay >> with TOFU) >> c) bail and talk to the resolver over port 53 >> >> In a), the resolver can be trusted. In both b) and c) the trust in the >> resolver doesn't really change from current status until DHCP >> authentication happens, but the query stream is hidden from other >> devices on the same network. Either way, the benefit is that stub >> resolver can make a decision based on a multitude of factors. Is there >> a merit in this, or am I perhaps missing something? >> >> Marek >> >> > >> > On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša >> > <mvavrusa=40cloudflare....@dmarc.ietf.org> wrote: >> >> >> >> Hi, >> >> >> >> this is a bit off topic, but I figured it would be useful to solicit >> >> some early feedback. The current status is that for secure (as in >> >> RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism, >> >> and it's also out of scope for [0]. At the same time we're seeing real >> >> world deployment of clients which either: >> >> >> >> a) Probe port 853 and use DoT in opportunistic profile, or probe 443 >> >> and trust WebPKI >> >> b) Statically configure ADN and/or SPKI pins with well known public >> >> resolvers >> >> >> >> This approach works if there's someone maintaining the statically >> >> configured information, as with the dnscrypt-proxy stamp lists [1]. >> >> However in most networks the default resolver configuration is pushed >> >> through DHCP, so it's the network operator that's in charge for >> >> providing default DNS resolver configuration (unless the user is a DNS >> >> aficionado and overrides it), but there's currently no good way to >> >> provide information required to identify and securely bootstrap a >> >> connection to a resolver using DoT or DoH. >> >> >> >> This draft adds an option to provide a capability list for each >> >> configured resolver. The three defined capabilities are TLS with SPKI >> >> pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this >> >> information and stores it similarly to resolver list and domain search >> >> path for applications to read. Another possible solution for this is >> >> to use the system of stamps from dnscrypt-proxy, but it's probably >> >> less legible for clients and duplicates information that's already in >> >> the recursive DNS nameservers DHCPv4/v6 option. >> >> >> >> The draft does not change the trust model, an end-user or an >> >> application can still disregard DNS recursive nameserver list from >> >> DHCP, for better or worse. >> >> >> >> Here's the draft: >> >> >> >> >> >> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt >> >> >> >> Marek >> >> >> >> [0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1 >> >> [1]: >> >> >> >> https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md >> >> >> >> _______________________________________________ >> >> DNSOP mailing list >> >> DNSOP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsop >> > >> > > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
