On Mar 12, 2017, at 8:17 AM, Jari Arkko <jari.ar...@piuha.net> wrote: > I would like to add that the issue is not just a process issue; > the questions one would have to answer (like how other > entities in the Internet should deal with the newly allocated > name) went unanswered. Maybe:
While this is true, it is not why we are doing the redact. We actually do the enumeration in homenet-dot. I think changing the text would confuse the issue by leading the reader to believe something that isn't true. Am I missing something? > However, there are first of all some unclear > details, but more importantly, I fear that the class of > name being requested is wrong. I say this with the > understanding that I’m not an DNS expert, but despite > efforts I have failed to understand the logic, and I can > see some issues in doing it the way that you’re crafting > the request. You use the word type later on, not class, so my initial reaction to this text was wrong. To be clear, I assume you are not proposing that we use a different CLASS value. > 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? This is addressed in points 4 and 5 of section 3. Your objection to the normative language in section 2 makes sense, though. > 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.) That makes sense. > 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? A validating stub will treat an un-signed RR in the zone as bogus if there is no un-signed delegation, because the absence of an un-signed delegation constitutes a secure denial of existence. The working group is well aware of the process issue—we've discussed it at length. We know that it's terra incognita, and may not go our way, but we want to try. Given that we're in last call, I suppose perhaps you are saying that you as a participant wish to see the consensus change; I would prefer not to have that discussion again. Is this what you are proposing, or are you just pointing this out in case the working group missed it? > To > prevent this from happening, it may be useful for the resolver to > identify different home networks on which it has resolved names, but > this is out of scope for this document. > > Even if this is outside the scope, it is not clear to me how this is > doable, given existing APIs. You can establish a process for establishing a trust anchor for any given homenet using trust-on-first-use of that zone's KSK. When you encounter a zone signed with a different KSK, this is by definition not the same zone, but is not treated as invalid: instead, you can cache multiple trust anchors (or be configured to treat other homenets as untrusted, or as invalid). This requires modifications to the stub resolver, obviously. There may be other issues with this solution as well, which is why it's out of scope for the current discussion, but you asked. :)
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
