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

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Mar 2017 13:17:28 +0100

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Mar 2017 08:41:38 -0400

> 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?

> see some issues in doing it the way that you’re crafting

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.

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

> level, could also be reduced security, e.g., if DNSSEC was not

That makes sense.

> 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?

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Mar 2017 13:45:01 +0100

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

Perhaps, but I wanted to be accurate as to why the original thing
wasn’t satisfactory. Your point about confusing with regards to
the current thing is of course valid. Presumably that could
be addressed by explicitly saying that there’s ongoing work
that intends to not make the same mistakes :-)

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

Right. Sorry. You can tell that I’m not a DNS expert… :)

>> level, could also be reduced security, e.g., if DNSSEC was not

Ok.

More later, gotta run. Thanks for the quick response!

Jari

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 12 Mar 2017 09:59:31 -0400

Hi,

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

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

> 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.)
 
> level, could also be reduced security, e.g., if DNSSEC was not

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.

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

> 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-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Mar 2017 08:11:13 -0400

> On Mar 12, 2017, at 9:59 AM, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi,
> 
> [...]

I agree with Andrew and think we need to consider this step quite carefully.  This text in the IANA considerations section:

does not explain that there is no process through which IANA can set up that delegation.  It may not even be an IANA process.  If this text were to be published in an RFC, I don't think IANA can carry out that instruction today, and I don't think IANA has the authority to negotiate a process through which it can carry out the instruction in the future.

I think this text should be modified in some way, before the document is published, to recognize explicitly that no such process exists today and that such a process is requested as part of the implementation of the published document.

The homenet WG is, I believe, aware of the need for a process for instantiating an insecure delegation as requested in the -dot document.  In my opinion, the implicit request for such a process should be made explicit in some way.

- Ralph

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Mar 2017 15:11:38 +0200

>> ICANN to invent such a process", I agree with the above.

This is my understanding as well.

> The homenet WG is, I believe, aware of the need for a process for instantiating an insecure delegation as requested in the -dot document.  In my opinion, the implicit request for such a process sho…

Good advice. Thanks.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Mar 2017 15:22:57 -0400

>  Names [1], or specify how other software should deal with

I just uploaded a new version of the doc with your proposed text.   Diff here:

https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-redact-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-redact-03>

I also updated the homenet-dot document, and you should have received a link to the diff under a separate cover, and of course the announcement also went to the mailing list, where I'm sure it was completely buried in all today's other timely submissions.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Mar 2017 21:48:11 +0200

Thanks. I won’t have time to review it today though.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Mar 2017 15:52:34 -0400

> Thanks. I won’t have time to review it today though.

Whyever not?   :)