On Sat, Aug 18, 2018 at 8:33 PM, Marek Vavruša <mvavr...@cloudflare.com>
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to