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

[Marek Vavruša <[e-mail]>]

On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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=[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
>> >
>> >
>
>