Hi, On Sun, Mar 12, 2017 at 01:17:28PM +0100, Jari Arkko wrote:
> I’m fine overall in requesting the allocation of .homenet for > this purpose. As I've already argued in this list, I think it's a mistake, but I'll try not to rehash that argument in what follows. (So if you detect such rehashing, please don't misunderstand it as what I've intended. I'm imperfect.) > Such queries MUST NOT be recursively > forwarded to servers outside the logical boundaries of the home > network. > > I’m not clear how to implement this MUST NOT. Is there > a requirement here that any recursive resolver either > knows about the logical boundaries of a home network, > or does not forward .homenet queries? It would seem that's an implicit requirement, but note that the requirement will never be met by anyone who doesn't implement this specification. Since basically every shipped home network box has some sort of forwarding or recursive DNS system in it, and they know nothing about homenet now, so they will just send the query out to the Internet. (This will be true of every domain name we pick for this.) > 2. Applications SHOULD treat domain names ending with '.homenet.' > just like any other FQDN, and MUST NOT make any assumption on the > level of additional security implied by its presence. > > This is fine, but that should probably be ‘… any assumption > about the security properties based on the use of this special > name.’ (It is not clear to me that there’d be additional security > level, could also be reduced security, e.g., if DNSSEC was not > locally available.) I don't think I understand this comment. But my understanding of the goal of homenet use cases was that most of the deployment needed to work without upgrading everything. So you should be able to use the homenet features with your unupgraded laptop, because it's supposed to Just Work like any other network context. So, > It is not clear to me why these are a requirement. it's because of the "Just Works" requirement. If you are validating on your laptop, your validator does not know about homenet, and so it won't know that when it gets the proof of non-existence of homenet. that it is supposed to ignore that proof. So it will treat any name beneath homenet as a bogus entry. > Also, the insecure delegation in the root zone puts us into a > place where we have not been before, process-wise, because > this is a special use domain name and a proper TLD at the same > time, causing us to run both the ICANN and the IETF process, As long as we understand "run the ICANN process" as including "getting ICANN to invent such a process", I agree with the above. > If we categorise .homenet as special, I don’t understand > why we need an insecure delegation. Software (e.g., > local resolver) would *know* this is a special name > and it would never be the case that .homenet suddenly > turns into a delegated secure regular domain which needs > the chain of trust from the root. What gives? Which "local resolver" do you mean? There could be more than one, and it's not only resolvers. You could do validation without doing resolution. Basically, to get homenet without the provably insecure delegation, you need to give up on validation or you have to accept that homenet techniques won't work until everything has been upgraded. (I suppose that, since we're assuming v6, we might be waiting for that anyway ;-) ) Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
