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
