Hi Stéphane, Thank you for reading the drafts. My responses are added in the text.
On Mon, Jul 16, 2012 at 4:09 PM, Stephane Bortzmeyer <[email protected]>wrote: > 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. > > The delegated domain name is under the ISP domain. If that is not clear, we will clarify it in the next version. In the current document, when the end user changes ISP, it has to change its domain name too. Actually the service the ISP provide name connectivity. Like IP addresses, phone numbers, email addresses, they are resources provided by the ISP and people understand that changing ISP, in most cases requires these resources to be changed. As Michael mentioned it is an important concern but not a new issue. The service ISP provides is different from providing a FQDN as registrars do. In order to benefit from this latest service, the end user can use CNAME/DNAME. CNAME / DNAME would need to be updated only when the end user changes ISP, rather than any time the Homenetwork is being assigned a new prefix. However, we will clarify this in the next version. > 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. > > Good points. First we have to mention these two alternatives in the next version, even though, I think we will consider it is the client's job to perform the key rollover. Secondly, the current document does not make possible to send multiple DS, so we have to add this in the next version. I am not sure we need to split the draft for DNS and DNSSEC, but we will ask the WG. 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.) > You are right it is a limited protection. ISPs have means to determine the mostly used FQDN of a zone. However, this requires much processing, than if the end user provides the list of its fqdn's hosts. We will mention this in the next version too. Thank you for reading the documents! Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
