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