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 <pusat...@bangj.com> wrote: > > > On Aug 18, 2018, at 8:53 PM, Marek Vavruša > <mvavrusa=40cloudflare....@dmarc.ietf.org> wrote: > > On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <mel...@fugue.com> wrote: > > 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. > > > 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 > > > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
