On Tue, 22 Oct 2013, Daniel Migault wrote:
By trusted relationship, I wanted to clarify that authenticating the DHCP
Server is not sufficient. The Client
MUST trust the DHCP Server. More specifically, when you are in a corporate
network you assume you are in a
trusted network, so you trust information from your DHCP Server. On the
contrary, in a cyber café, even if you
authenticate the DHCP Server as the one of the cybercafé, you do not
necessarily trust it to the point to accept
crucial information.
I'm not sure I agree. When I am in a corporate network, I don't want it
to give me trust anchors for nohats.ca regardless. It does not matter to
me whether it is a large enterprise or a starbucks wifi.
I think at most, it should be allowed to give me a trust anchor for the
domain option it gives me, meaning to re-arrange trust for the LAN I
just entered. Although that moves the security issue to when I should or
should not accept a domain option from DHCP. I still don't want
starbucks to give me a nohats.ca search domain and modify its trust
anchor.
Practically, this means that these Options must be 1) considered cautiously by the DHCP
Client and 2) "only" when
they are provided by trusted networks, that is mostly the corporate network, or
the DSL line at home.
That would require marking networks as "trusted" in your network manager
program by the end user.
The reason to use certificate is that ISP will not deploy DNSSEC in DSL boxes,
if they have no way to push
securely the valid KSKs.
I _really_ don't want ISPs pushing trust anchors. Enterprise LAN setups,
home networks, sure. But not random hotspots or random ISPs. DNSSEC
deployment _protects_ me from bad ISPs (like Rogers Canada) who mangle
the DNS for me with "sitefinder" like ads. There have been ISPs with poisoned
caches or malicious employees trying to get adviews. ISPs can and should
provide a DNS caching resolver I can use, but they cannot be trusted to
set any DNSSEC trust anchor.
I saw certificate as one way to provide authenticated information, and this
information
can be provided over untrusted/unsecured/unauthenticated channels.
True that if the device is desynchronized, signature checks cannot be
performed neither for DNSSEC nor for
certificates. To use certificates the device needs a valid CA and a proper
time. If the device is desynchronize,
it should use the time value provided by the DHCP Time Option. This only works
if provided by a trusted DHCP
Server. As a result, for a desynchronized device it may not provide any
advantages, and sending the KSK
insecurely is much simpler.
But if the client needs that much certificate processing capability, why
not just have the client do that straight against the ICANN pem bundle?
That works better too if the device changes hands (as old devices often
do)
The only reason I see here is to have corporate issued devices take on
the non-public corporate trust anchors. I don't think enterprise device
management needs an internet protocol. They should just grab the device
and bring it up to date with its OS/firmware before redeploying it on
their internal network. You shouldn't be deploying unpatched years-old
devices on a corporate lan anyway.
The big issues I see are:
1) It only applies to the Root Key. Which means the CPE cannot recover for
example from TLD that had an
emergency roll over.
But the root key is special. for all other emergency rollovers, flush
your DNS cache and try again?
2) If does not provide the ISP to mitigate a key roll over issue performed
on the Internet. If a problem
occurs, the end user will not call ICANN.
They should call Microsoft, Apple, Google, or their Linux vendor
instead. Giving ISPs so much trust power to override an enduser's trust
anchors is just not safe.
For enterprise devices, I would assume that an unfiltered internet
connection is not available (firewalled, etc) so it might need something
else. However, there is likely good reason to have trust in the LAN,
and a time estimate could be obtained from the NTP server through DHCP
(option 42 could provide an IP address for one entry, therefor removing
the need for DNS to obtain NTP)
Good point, providing IP addresses makes DHCP Time Option unnecessary.
Difference between ntp client vs DHCP Options is that using ntp client adds
round trip, and requires the ntp
client to be installed. If that does not cause any problems, then we should use
option 42.
Even most cheap $30 wifi/routers have ntp these days. the only category
that might not have it is the "internet of things" kind of devices. But
those would not use DNS(SEC) either I think.
I see your point with split-views.
which I think is really the most important trust anchor hand-over to
deal with. And your draft might be used for that!
I should add this to the draft. I agree that CERT may not be very useful in
LAN or trusted environment. On the other hand it would really help that ISPs
can provision the devices with KSKs
and authenticate them.
I _really_ don't want ISPs changing trust anchors. We are moving DNSSEC
to the endnode because we cannot trust either the ISPs or the link
between the ISPs and us.
In addition I would like also a standard way to store KSK in certificate.
While I'm really trying hard to keep DNS in DNS only :)
A discussion would be very helpful to talk about the various security
implications, and to ensure that we can keep the differences between
DHCP and IKEv2 options for VPN as small as possible.
Definitely. I have not mentioned VPN use cases, but we should consider this
case with more attention. Wen you say
"as small as possible" do you mean that we should also define new CP
attributes? I am sure I must misunderstood
something, but I expect the VPN client to get the DHCP Server address from the
security gateway(INTERNAL_*_DHCP)
and from that the client sends the ORO to the DHCP Sever.
Each option that we add to DHCP for DNS reconfiguration is an option we
would need to have an IPsec gateway relay via IKE as well to remote
clients so being remote or local ends up with the same DNS configuraion.
Of course, the advantage of IPsec is that it is all authenticated,
unlike DHCP.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
