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

[Andrew Sullivan <[e-mail]>]

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
[e-mail]