We should solve two problems: 1) trust problem 2) encryption problem No matter whether we adopt DHCP, it's better to solve them separately. I mean that it's OK if two solutions are used for these two problems.
Best Regards, Zhiwei Yan > 在 2015年4月14日，下午5:46，Linhui Sun <lh.sunl...@gmail.com> 写道： > > HI, Daniel > > I think there is no difference when we considering which to do first. If the > DHCP could offer a better way, that would be fine. However, there are several > problems in the authentication mechanism defined in RFC3118, thus the dhc WG > developed another mechanism called secure DHCP > (http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ & > http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/) to enhance the > RFC3118. > > I think the key point is whther we could trust a DHCP server just as Melinda > mentioned. I'm not sure whether the secure DHCP could solve the "trust" > problem, I just provided it here for reference only. If possible, an > extension to DHCP may be a good way. Comments are welcome. > > Best Regards, > Linhui > > 2015-04-14 12:36 GMT+08:00 Daniel Kahn Gillmor <d...@fifthhorseman.net>: >> [ 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 >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
