On Wed, 23 Oct 2013, Daniel Migault wrote:
2) Security Models
I am not sure I have been clear enough on the security model or the use case
I am considering in my draft. I hope I am clarifying this point now.
My device -- say a CPE or smartphone, my PC -- only performs DNSSEC
resolutions, that is to say always perform signature checks, and so MUST
have valid KSKs, even when a emergency key roll over is performed.
I am not sure if you need to address emergency rollovers. There are ways
using prepublishing of future KSKs to address emergency rollovers. CPE's
don't need to know anything about that. You are adding to confusion by
using "rollover" and not "emergency rollover" below. Rollovers cause no
problems. Well prepared emergency rollovers cause no problem. Badly done
emergency rollovers cause inevitable problems for everyone.
Suppose a CPE is attached with a wire connection and performs DNSSEC
validation for my Home Network. Suppose a KSK roll over is performed by
.tld. There are two possibilities:
There should be no issue for the CPE. A proper DS will be in the root
for the old and new key before they roll. It can validate signatures
from the old and the new key. When it rolls, there is no problem.
The big problem for CPE's is when they miss a root key rollover because
they were on the shelve for a few years.
- a) information received by the DHCP Server is reliable,
- b) information received by the DHCP Server is not reliable.
If this truly is an emergency rollover that was ill prepared, than the
DHCP server is in the same boat at the CPE. No one has the right
information. At best you can flush your entire cache and hope DS record
at the parent (or root) is valid.
Suppose a smartphone is attached to a random WLAN AP and a KSK roll over is
performed by .tld. Updating KSKs is necessary.
No it's not. See http://tools.ietf.org/html/rfc6781
Suppose a smartphone attached to your home network WLAN AP or a wire line.
The attachment is secured with WPA2 for example. The smartphone updates its
KSKs the same way the CPE does it.
Didn't you just move the problem from the phone to the CPE. Where does
the CPE get its update from. How can the CPE trust it? And why can't the
phone use the same method?
Suppose the smartphone is attached to a random WLAN AP. The DHCP Server
provides a KSK for the attached domain. This KSK MUST only be used for that
domain and MUST be removed when the smartphone changes its administrative
domain.
Right. Now this is the REAL problem that you might be able to solve with
DHCP. You enter a split-dns view and the network uses a DNS domain that
is not visible in the public view. The smartphone cannot resolve down
from its trusted root key to validate this domain. The smartphone and
the DHCP server have to agree on a "DNS lie". How to authenticate that?
The problem is, the dns domain relayed itself insecurely. Let's say my
phone uses some non-FQDN like "mail". When a DHCP network tells me the
current LAN domain is "google.com", they can intercept my mail meant to
go to google (We have TLS to protect us currently)
Worse, if they can convey a trust anchor for "google.com" then they
could potentially MITM all my real google connections. (Imagine they
put their own TLS key in their local "google.cmo" TLSA record)
So if you want to convey a KSK for a dns domain, you need to establish
some way for the phone to be able to agree to the domain and trust
anchor. Let's assume that the transport is secure (like WPA2 enterprise
or whatever) - how does the phone make a choice about the vaildity of
the dns dmain received. And when it does, then it can also decide to
temporarilly trust that trust anchor.
The "temporarilly" bit is done by flushing the cache, which you must do
anyway. For example, when I use my VPN to connect to redhat.com, the VPN
reconfigures my DNS for "redhat.com" to point to a 10.a.b.c DNS server.
I can now resolve internal-only redhat.com names. But also, other DNS
names just get their internap IP. bugzilla.redhat.com gets an internal
IP address. When I disconnect, I need to access bugzilla.redhat.com by
its external IP. Therefor, the VPN software (openswan/libreswan) and
NetworkManager (for openvpn/vpnc) flush the cache and request-list
whenever the VPN comes up or goes down.
Remarks:
- a) We need to define what a Trusted DHCP Server is.
Yes. I would try something like "one you physically connect to, or use a
password for (eg wireless)". By connecting to such a network, the user
implicitely conveys trust in the dhcp server. (however, it should still
do due diligene before accepting random domains and trust anchors but I
don't know how it can do that)
- b) KSKs other than KSKs with local scope are between configuration and
"local" setting for connectivity.
I think KSKs other that local scope should never be considered with a
possible acception of the root trust anchor.
3) Trust DHCP Server
The draft assumes a trust relation between a DHCP Server and a DHCP Client.
Removing the Time Option reduces the necessity of this requirements.
Not realy. See above example of a rogue network telling me it is
"google.com".
5) CERT for KSKs
It seems that some do not like the idea that KSKs are provided via CERT.
First, I agree we should find a CA that is almost unlikely to perform key
roll over. Then, a "KSKs TA office" may be created ;-). It does not exist
yet, so I mentioned ISPs in my draft, but I could have specified any third
party. I have no problem with that.
It creates the same problem the root key has. Now you have two such
problems.
Paul
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
