[ rearranging for chronological sanity ] On Tue 2015-04-14 00:02:24 -0400, Zhiwei Yan wrote: > [ Paul Wouters wrote: ] >> On Tue, 14 Apr 2015, Zhiwei Yan wrote: >>> Then why not consider the DHCP? >>> DHCP can support client authentication and can be used to configure the RS >>> key on the authenticated client. >>> Do you think this will help? >> >> How do you know the DHCP server is not a rogue attacker? >> How does the system determine encrypting to the DHCP/DNS server is >> guaranteed to not be eavesdropped on? >> It depends on if I trust that network (eg my home) or not (eg starbucks) > > RFC 3118 provides a scheme for this issue: > http://www.rfc-base.org/txt/rfc-3118.txt
Haven't we just pushed the problem off a level then? It seems you've replaced the problem "how do i choose a trust anchor for my DNS server" with "how do i choose a trust anchor for my DHCP server"? And the trust anchor framework described in 3118 is pretty weak compared to the trust anchor frameworks we have available in TLS (problematic though some of them may be): Key Utilization: https://tools.ietf.org/html/rfc3118#section-5.4 Key Management: https://tools.ietf.org/html/rfc3118#page-16 In those scenarios where a trust relationship already exists between a DHCP client and a DHCP server, sure, we should figure out a way to distribute DNS resolver trust information as well, once we know what that looks like (e.g. a DHCP extension containing a SHA256-sum of the DNS server's subjectPublicKeyInfo would be plausible). But again, that seems like a nice thing to have *after* we've sorted out what the DNS trust anchor looks like in the manually-configured case. --dkg _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
