Re: [dns-privacy] Considering DHCP

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.sunlinh@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 <dkg@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