Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Ted Lemon <[e-mail]>]

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=[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>