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
