Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ted Lemon writes:
> On Dec 15, 2016, at 2:23 PM, Steve Crocker <[e-mail]> wrote:
> > I dont understand what is meant by an unsecured delegation.  I also
> > dont understand what sort of delegation you want, irrespective of whether
> > DNSSEC is involved.
>
> There would be a delegation for .homenet in the secure root, which would
> point at the AS112 servers, and would have no DS records.

I think where the delegation points to is still under debate.  To
make DNSSEC work all that is required is that it a insecure (not unsecure,
there was a lot of debate about the term to use years ago) delegation
which means one without a DS record.

The AS112 server are definitely the wrong set of servers to delegate
to as they are not configured to serve the zone and cannot be made
to serve the zone with reliability.  A different set of anycast
servers however would do.

> > I think there are two very big hurdles implicit in I think we should
> > ask ICANN to set up   One is the technical hurdle of whether this is a
> > sensible thing technically with respect to the security and stability of
> > the Internet.  It will take a fairly long time and a lot of analysis for
> > ICANN to get comfortable with such a result, and I would not count on a
> > positive outcome.
>
> Yup, understood.
>
> > Thats the first hurdle.  The second hurtle may be even harder.  The
> > only existing procedures for adding new delegations to the root are for:
> >
> > o New ccTLDs, i.e. when new countries are created and get two letter
> > codes from the ISO 3166 Maintenance Agency;
> >
> > o New IDN ccTLDs via the Fast Track; and
> >
> > o New gTLDs through the gTLD process.
> >
> > The first two would not apply.  The window for the third was closed a
> > while ago and we are studying when and how to reopen the window.  The
> > process is geared toward prospective operators of registries.  A
> > substantial fee is required, and an even more substantial investment in
> > registry operation is required.
>
> It would not make sense to follow any of these processes.   This is a
> technical allocation under the terms of the MoU, and we dont actually
> know how to do those.   It would, in my view, be extremely weird for
> ICANN to charge IETF for doing one of these, based on my reading of the
> MoU, but at the same time ICANN is responsible for operating the zone, so
> its entirely reasonable for ICANN to say "no, we wont do that," and then
> the IETF would have to decide that that meant in terms of the MoU.   I
> would hope that ICANN would not do this, and I think the MoU seems to
> indicate that they have agreed not to, but its uncharted territory, and I
> think there would have to be a fourth process for this, which is separate
> from the three you described above.
>
> > I suspect whats intended here is something qualitatively different,
> > e.g. some sort of entry in the root that returns a fixed result, not a
> > pointer to name servers.
>
> No, just a delegation to AS112 with no DS record would do the job, unless
	s/AS112/anycast/
> I am missing something.   I will admit to not being an expert on DNSSEC
> arcana, so thats entirely possible.
>
> >  Aside from the technical questions I mentioned above, we would also
> > have to sort out the policy questions, e.g. what are the rules for
> > accepting such requests, what happens if there are competing requests,
> > and perhaps others that arent occurring to me as I write this.
>
> Yes.   Its a big can of worms.   We wont know precisely whats in it
> unless we open it.
>
> >>   In order for names under .homenet to be validated by DNSSEC, it
> >> would be necessary for the validating resolver to have a trust anchor for
> >> any homenet on which it wants to do validation, and a means of
> >> differentiating between home nets so that it doesnt use the wrong key to
> >> validate.
> >
> > Yes, but the way the sentence is written suggests this would difficult
> > or odd.  In a homenet environment, if you have a local name server
> > responding to requests as an authority, it can sign those requests as the
> > authority.  The requesting resolver will have to have the public key
> > associated with the authority.  This is a configuration matter.  When the
> > requesting resolver is told which resolver on the edge of the homenet is
> > authoritative for the homenet environment, it should also learn that
> > resolvers public key.  This seems like a DHCP issue.
>
> I dont think DHCP is the right answer, but the bottom line is that this
> isnt really the issue that we need to figure out right now.   Just bear
> in mind that a validating stub resolver needs to not invalidate answers
> that are returned within .homenet.
>
> >>   But thats out of scope for this discussion: the point of this
> >> discussion is simply to figure out whether we want to do the hard thing
> >> or the easy thing: .homenet or home.arpa.
> >
> > I dont see a difference between .homenet or home.arpa in this regard.
>
> If the working group chose to use home.arpa, we would not need to open
> the aforementioned can of worms.

The can of worms is going to need to be opened anyway.  There is
another draft on .localhost which will open it if homenet doesn't.
It that doesn't then the special names discussion will open it.  I
don't see the can of worms staying closed.

The IETF and ICANN are going to need to address this issue.  It
does no one any good to leave it festering.

The only decision to make is homenet going to wait for that discussion
to occur or not.

Mark

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]