[homenet] review of draft-ietf-homenet-redact and draft-ietf-homenet-dot

[Jari Arkko <[e-mail]>]

I have reviewed these two documents today, and had
some comments:

redact:

Seems fine. But on:

  RFC7788
  did not follow the process defined in Special Use Domain
  Names [1].

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:

  RFC7788
  did not follow the process defined in Special Use Domain
  Names [1], or specify how other software should deal with
  the allocated name.

dot:

I’m fine overall in requesting the allocation of .homenet for
this purpose.

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.

   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?

 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.)

   5.  Only a DNS server that is authoritative for the root ('.') or is
       configured to be authoritative for '.homenet' or a subdomain of
       '.homenet' will ever answer a query about '.homenet.'  In both of
       these cases, the server should simply answer as configured: no
       special handling is required.

   …

   IANA is requested to set up insecure delegation for '.homenet' in the
   root zone pointing to the AS112 service [RFC7535], to break the
   DNSSEC chain of trust.

This is the concern about the type of a name being requested
that I mentioned above.

It is not clear to me why these are a requirement.

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,
and I think this might also imply things at least at the moment
that we don’t like, such as a requirement to sign the TLD,
which would be contrary to our stated goals here.

Furthermore, I don’t understand the technical motivation,
despite having read plenty of email on this topic and having
asked friends. But maybe I’m being dense today. Probably.

But, here’s my thinking.

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?

   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.

Jari