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-ietf-dhc-sedhcpv6/] &
http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/
[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
[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
[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
[https://tools.ietf.org/html/rfc3118#section-5.4]
Key Management:
https://tools.ietf.org/html/rfc3118#page-16
[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 [dns-privacy@ietf.org]
https://www.ietf.org/mailman/listinfo/dns-privacy
[https://www.ietf.org/mailman/listinfo/dns-privacy]
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
