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

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

Thanks Tom, this is what I was asking for. I'll take a look!

On Sat, Aug 18, 2018 at 6:09 PM, Tom Pusateri <[e-mail]> wrote:
>
>
> On Aug 18, 2018, at 8:53 PM, Marek Vavruša
> <mvavrusa=[e-mail]> wrote:
>
> On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <[e-mail]> wrote:
>
> On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <[e-mail]>
> wrote:
>
>
> 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
>
>
>
> The document explicitly says that it doesn't have a trust model for DHCP.
>
>
>
> The "DHCP authentication" does exist, I believe you're referring the
> deployment status.
>
>
>
> No, I'm referring to it doesn't exist.   There is no deployable DHCP
> authentication.   The DHC working group tried to come up with one, and
> ultimately concluded that it was not worth it, because the only thing that
> should ever be trusted from a DHCP server is information about the local
> network.   DoH and DoT are out of scope for DHCP according to this
> reasoning.   Bear in mind that we were more optimistic about authentication
> when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
> RFC3315, is not as optimistic, and only provides for authentication using
> IPsec between server and relay, and authentication for the purpose of doing
> Reconfigure; this authentication is not sufficient to provide assurances of
> trustworthiness.   It's about as secure as a TCP sequence number.
>
>
> 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.
>
>
>
> There is a way forward: seriously figure out the threat model.   Tom
> Pusateri and another author already did a DHCP document; the reason we
> didn't advance it is that we weren't able to come up with a threat model
> where configuring DoT or DoH made sense.   Until someone does that, there is
> no point in doing further work on a DHCP option.   If we do do further work
> on a DHCP option, Tom's document is more complete than yours.
>
>
> Can you share the link for the draft for a reference?
>
> Marek
>
>
> Marek,
> I sympathize with your desire to deploy DNS over TLS. That was the
> motivation for Willem Toorop and I to go down this road and present it at
> Montréal IETF DRIU BOF. Ted challenged me as well but I didn’t understand
> his point before I presented our work. Ted gave an excellent rebuttal talk
> after mine that was very clear about how DHCP should really only be used to
> bootstrap configuration information enough to then talk to more trusted
> services due to lack of authentication and lack of trustworthiness when
> connecting to unknown networks.
>
> You should first of all go listen to Teds talk (not a TED Talk) from the
> DRIU BOF. The video is here: https://www.youtube.com/watch?v=cfEX8zuoRAA
> Ted’s talk starts at 33:18.
>
> Willem and my draft is here:
>
> https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00
>
> My talks on threats and this draft are in the archives of the DRIU BOF and
> in the same video as Ted.
>
> Aside from Ted, there was a strong consensus in the room to not adopt our
> draft. You can listen to the comments at the microphone for more
> information.
>
> Thanks,
> Tom
>
>
>
>
>