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

[Ted Lemon <[e-mail]>]

https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-13

On Sat, Aug 18, 2018 at 8:53 PM, Marek Vavruša <[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
>