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.
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 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 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. 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
