On Tue, Jul 03, 2012 at 12:11:54PM +0200,
Daniel Migault <[email protected]> wrote
a message of 155 lines which said:
> Please find two Naming Architectures we would like to discuss at Vancouver:
I won't be in sunny British Columbia but I've read the drafts and I
have a philosophical question. You did not say clearly if the
delegated domain must be under an ISP's domain. If yes, it ties the
user to the ISP ("I've switched ISPs, use
<http://fridge.migault.free.fr/> and no longer
<http://fridge.migault.orange.fr/>"). If no, the ISP won't be able to
update the DNS delegation. IMHO, it would be a good idea to have a
high-level discussion of the service provided to the user, before
getting into protocol details.
A technical remark: since the DS record is sent by the client, one can
assume that it may suddenly be a new one (key rollover). Then, DNSSEC
validation will break for validators which have the old DS in the
caches. Two possible solutions: have a very low TTL, or just say that
it is the client's job to do rollovers properly (having two DS in
parallel, etc). The second solution implies that the CPE includes
rollover logic (like OpenDNSSEC does). DNSSEC in practice is hard and
you may want to have two drafts, one without DNSSEC and one for DNSSEC
gory details.
Also, a security remark. When you say:
> First delegation preserves the Home Network privacy, by avoiding ISP
> to know the Home Network hosts.
It certainly deserves a mention in Security Considerations saying that
it is a limited protection. Many names will be predictible ("printer",
"fridge", "nas", "iPad") and also the first DNS request to the parent
domain (which is probably controlled by the ISP) will include the
FQDN, thus revealing a name. (And I did not even mention the ability
of the ISP to sniff the network.)
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
