Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

From: Brian Dickson <[email-masked]>
Date: Mon, 20 Mar 2017 15:08:43 -0700

> Hi,
> The INT Area Director who oversees the homenet WG, Terry Manderson, has
> asked DNSOP participants to review
> https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt, "Special Use Top
> Level Domain '.homenet’”, with the following aspects in mind:
> 1) in terms of RFC6761
> 2) in terms of the _operational_ position of an unsigned entry in the root
> zone as requested in this document, to break the chain of trust for local
> DNS resolution of .homenet names.
>

I'd like to ask some questions about homenet and the TLD.

These are mostly clarification questions, but might (together) lead to an
alternative solution.

   1. The homenet TLD is intended to be used in such a way that queries
   should never reach the root servers. Is this correct?
   2. The main issue driving the request for the insecure delegation, is
   the ability to have a proof of insecurity anchored at the ICANN
   root-of-trust, aka the KSK for the root zone. Is this correct?
   3. Resolvers doing "homenet" need to be able to serve current "proof"
   responses, whose signatures' validity periods are "current". Is this
   correct?
   4. What is required for the above, is generation of DNSSEC records
   including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.

Since the queries are never meant to reach the root servers, the presence
or absence of "homenet" in the root is mostly moot.

The only technical requirement is that suitable DNSSEC records be
generated, and that the special-purpose homenet DNS resolvers are able to
have up-to-date copies of these DNSSEC records.

As a technical matter, this does not require publishing these records in
the root zone, although that would be one way of achieving the necessary
requirement.

Perhaps the homenet WG folks could talk to the ICANN folks about ways of
accomplishing the above, without the need for publishing the unsigned
delegation in the root zone?

The benefit of not publishing, is that any queries that do hit the root
servers, would get a signed NXDOMAIN, which IMHO is a more correct response.

(It also prevents the problem of what NS values would need to be used on
the unsigned delegation.)

Brian

> This document is the product of the homenet WG, which has asked the IESG
> to approve it for publication, so our comments are strictly advisory to the
> IESG. There was some discussion of the draft on this list shortly after it
> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
> additional review.
>
>
> thanks,
> Suzanne & Tim

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 21:25:40 -0400

I'm curious what Russ and Steve think about this as an alternative.   It seems a bit byzantine to me, but I can't say that I object to it on principal.   It does create a lot of extra work for ICANN, though, and it would be a bit more brittle than just doing an unsigned delegation: we now have to have some way to get current versions of these signatures into the homenet resolver.

Further comments inline.

On Mar 20, 2017, at 6:08 PM, Brian Dickson <[email-masked]> wrote:
> What is required for the above, is generation of DNSSEC records including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.

Yes.

> Since the queries are never meant to reach the root servers, the presence or absence of "homenet" in the root is mostly moot.

Sure.

> The only technical requirement is that suitable DNSSEC records be generated, and that the special-purpose homenet DNS resolvers are able to have up-to-date copies of these DNSSEC records.

Sure.

> As a technical matter, this does not require publishing these records in the root zone, although that would be one way of achieving the necessary requirement.

True.

> Perhaps the homenet WG folks could talk to the ICANN folks about ways of accomplishing the above, without the need for publishing the unsigned delegation in the root zone?

Strictly speaking I think this is something the IESG would have to do.  I don't object to this as a solution, but operationally I think it's a lot more work.   It may be that it's worth doing it, since it might be applicable to other special-use name allocations.

> The benefit of not publishing, is that any queries that do hit the root servers, would get a signed NXDOMAIN, which IMHO is a more correct response.

Yes.   I'm not sure that's enough to justify the extra work.

---

From: Steve Crocker <[email-masked]>
Date: Mon, 20 Mar 2017 21:37:14 -0400

Before addressing the questions you've asked, let me about the rest of the picture.  How do names get assigned within the local homenet domain?

Steve

Sent from my iPhone

> On Mar 20, 2017, at 9:25 PM, Ted Lemon <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 21:43:46 -0400

> Before addressing the questions you've asked, let me about the rest of the picture.  How do names get assigned within the local homenet domain?

Using either hybrid dnssd, or else stateful dnssd.   So,

https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-00 <https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-00>
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-06 <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-06>
https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 <https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00>

The short answer is that names are discovered on the local wire using Multicast DNS (RFC 6762) and published using DNS Service Discovery (RFC 6763).   The former is a link-local protocol; the latter is the DNS wire protocol, with some special features.   The drafts I linked to talk about that in detail, but it's a lot of reading.   I think the first one gives you a decent sketch, but it's a -00, so it could probably be a lot more clear.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 20 Mar 2017 18:50:21 -0700

Just to follow through on my thought(s) on this... (thought in-line below).

On Mon, Mar 20, 2017 at 6:25 PM, Ted Lemon <[email-masked]> wrote:

> I'm curious what Russ and Steve think about this as an alternative.   It
> seems a bit byzantine to me, but I can't say that I object to it on
> principal.   It does create a lot of extra work for ICANN, though, and it
> would be a bit more brittle than just doing an unsigned delegation: we now
> have to have some way to get current versions of these signatures into the
> homenet resolver.
>

Given that hypothetically this would not be published in the root zone,
there are ways to make this less brittle or expensive.
(Apologies in advance to anyone who might sprain their eyebrows.)

Technically, it is possible use the KSK instead of the ZSK in generating an
RRSIG.
This would alleviate the temporal nature of validation from ZSK-derived
RRSIGs. (Continue reading for why this matters.)

And also technically, an RRSIG can have a nearly-arbitrary validity period,
up to 68 years.

So, if ICANN were to agree to do so, they could provide a long-lived RRSIG
signed directly by the root trust anchor, aka the KSK of the root zone.
This would validate for however long the RRSIG's validity period is, or
until the KSK rolls.

This would require an update every time the KSK is rolled, or whenever the
RRSIG needs to be refreshed. 68 years is an inconvenient interval, so maybe
50 or 20 years? This is still a lot better than 1 week or 1 month.

The question of how to publish this is orthogonal; perhaps some existing or
new RRTYPE, at some well-known place in the DNS tree, maybe under ".arpa"
somewhere convenient? Ideally also DNSSEC-signed.

Just suggesting something that is technically feasible...

Brian

>    1. What is required for the above, is generation of DNSSEC records
> Strictly speaking I think this is something the IESG would have to do.  I
> don't object to this as a solution, but operationally I think it's a lot
> more work.   It may be that it's worth doing it, since it might be
> applicable to other special-use name allocations.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Mar 2017 21:54:37 -0400

On Mar 20, 2017, at 9:50 PM, Brian Dickson <[email-masked]> wrote:
> This would require an update every time the KSK is rolled, or whenever the RRSIG needs to be refreshed. 68 years is an inconvenient interval, so maybe 50 or 20 years? This is still a lot better than 1 week or 1 month.

Isn't there some inconvenient process involved in using the KSK?   I suspect that in practice, this makes it harder, not easier.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 20 Mar 2017 19:14:35 -0700

On Mon, Mar 20, 2017 at 6:54 PM, Ted Lemon <[email-masked]> wrote:

> Isn't there some inconvenient process involved in using the KSK?   I
> suspect that in practice, this makes it harder, not easier.
>

Yes, very much so, although I'm answering from second- or third-hand
knowledge.

As I understand it, the whole process of using the KSK is a scripted,
recorded ceremony in a carefully controlled super-restricted environment,
so this would need to be added to that script.

On the plus side, if it only needs to be done on the very rare occasion
(every N years or when the KSK rolls), I think the benefit would outweigh
the initial barrier to change.

But, that is probably for the folks with direct knowledge to comment on.
I'm just putting the suggestion forward.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Mar 2017 17:09:14 +1100

In message <CAH1iCioEAfgS-Efj1OYsL1vG4STnwod=[email-masked]>, Brian Dickso
n writes:
> --===============2842493287922721238==
> Content-Type: multipart/alternative; boundary=94eb2c0685ce434e95054b30c544
> 
> --94eb2c0685ce434e95054b30c544
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> > Hi,
> > Level Domain '.homenet=E2=80=99=E2=80=9D, with the following aspects in m=
> ind:
> > 1) in terms of RFC6761
> > 2) in terms of the _operational_ position of an unsigned entry in the roo=
> t

No.  Homenet DS are expected to reach the root.

>    root-of-trust, aka the KSK for the root zone. Is this correct?

Proof the the homenet exists as a zone and that it is insecurely delegated.

>    including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homenet" TLD.

NSEC and RRSIG(NSEC).  The NS records at the delegation are unsigned.
There also need to be servers that respond with NXDOMAIN for names
below homenet and return NS and SOA RRsets for homenet that the
delegating NS records for homenet point to.

Below is invalid as it is built on a incorrect set of assumptions.

> servers, would get a signed NXDOMAIN, which IMHO is a more correct response=
> .
> 
> > to approve it for publication, so our comments are strictly advisory to t=
> he
> > IESG. There was some discussion of the draft on this list shortly after i=
> t
> > appeared, in November 2016, but it=E2=80=99s always the AD=E2=80=99s prer=
> ogative to ask for
> > additional review.
> >
> >
> > thanks,
> > Suzanne & Tim
> 
> --94eb2c0685ce434e95054b30c544
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><table width=3D"100%" style=3D"color:rgb(0,0,0);font-famil=
> y:times;font-size:medium"><tbody><tr><td><blockquote class=3D"gmail_quote" =
> style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
> dding-left:1ex">Hi,<br class=3D"gmail-">The INT Area Director who oversees =
> the homenet WG, Terry Manderson, has asked DNSOP participants to review=C2=
> =A0<a rel=3D"nofollow" href=3D"https://www.ietf.org/id/draft-ietf-homenet-d=
> ot-03.txt" class=3D"gmail-">https://www.ietf.org/id/draft-ietf-homenet-dot-=
> 03.txt</a>, &quot;Special Use Top Level Domain &#39;.homenet=E2=80=99=E2=80=
> =9D, with the following aspects in mind:<br class=3D"gmail-">1) in terms of=
>  RFC6761<br class=3D"gmail-">2) in terms of the _operational_ position of a=
> n unsigned entry in the root zone as requested in this document, to break t=
> he chain of trust for local DNS resolution of .homenet names.<br class=3D"g=
> mail-"></blockquote><div><br></div><div>I&#39;d like to ask some questions =
> about homenet and the TLD.</div><div><br></div><div>These are mostly clarif=
> ication questions, but might (together) lead to an alternative solution.</d=
> iv><div><br></div><div><ol><li>The homenet TLD is intended to be used in su=
> ch a way that queries should never reach the root servers. Is this correct?=
> </li><li>The main issue driving the request for the insecure delegation, is=
>  the ability to have a proof of insecurity anchored at the ICANN root-of-tr=
> ust, aka the KSK for the root zone. Is this correct?</li><li>Resolvers doin=
> g &quot;homenet&quot; need to be able to serve current &quot;proof&quot; re=
> sponses, whose signatures&#39; validity periods are &quot;current&quot;. Is=
>  this correct?</li><li>What is required for the above, is generation of DNS=
> SEC records including RRSIG(NS), NSEC, and RRSIG(NSEC), for &quot;homenet&q=
> uot; TLD.</li></ol><div>Since the queries are never meant to reach the root=
>  servers, the presence or absence of &quot;homenet&quot; in the root is mos=
> tly moot.</div></div><div><br></div><div>The only technical requirement is =
> that suitable DNSSEC records be generated, and that the special-purpose hom=
> enet DNS resolvers are able to have up-to-date copies of these DNSSEC recor=
> ds.</div><div><br></div><div>As a technical matter, this does not require p=
> ublishing these records in the root zone, although that would be one way of=
>  achieving the necessary requirement.</div><div><br></div><div>Perhaps the =
> homenet WG folks could talk to the ICANN folks about ways of accomplishing =
> the above, without the need for publishing the unsigned delegation in the r=
> oot zone?</div><div><br></div><div>The benefit of not publishing, is that a=
> ny queries that do hit the root servers, would get a signed NXDOMAIN, which=
>  IMHO is a more correct response.</div><div><br></div><div>(It also prevent=
> s the problem of what NS values would need to be used on the unsigned deleg=
> ation.)</div><div><br></div><div>Brian</div><div><br></div><div>=C2=A0</div=
> ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
> -left:1px solid rgb(204,204,204);padding-left:1ex">This document is the pro=
> duct of the homenet WG, which has asked the IESG to approve it for publicat=
> ion, so our comments are strictly advisory to the IESG. There was some disc=
> ussion of the draft on this list shortly after it appeared, in November 201=
> 6, but it=E2=80=99s always the AD=E2=80=99s prerogative to ask for addition=
> al review.<br class=3D"gmail-"><br class=3D"gmail-"><br class=3D"gmail-">th=
> anks,<br>Suzanne &amp; Tim</blockquote></td></tr></tbody></table></div>
> 
> --94eb2c0685ce434e95054b30c544--
> 
> 
> --===============2842493287922721238==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============2842493287922721238==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]