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

From: Suzanne Woolf <[email-masked]>
Date: Wed, 14 Dec 2016 11:11:39 -0500

Hi all,

DNSOP participants who are interested in the special use names problem might want to review draft-ietf-homenet-redact (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/ <https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/>) and draft-ietf-homenet-dot (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ <https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/>) for the WGLC on them in the HOMENET wg.

WGLC comments should go to the WG list, [email-masked] <mailto:[email-masked]>.

If you do, it will also be helpful to look at RFC 7788, which specifies the Home Networking Control Protocol for homenets. 

The redact draft is intended to remove the inadvertent reservation of “.home” as the default namespace for homenets in RFC 7788. 

The homenet-dot draft is intended to provide a request under RFC 6761 for “.homenet” as a special use name to serve as a default namespace for homenets. It also asks IANA for an unsecured delegation in the root zone to avoid DNSSEC validation failures for local names under “.homenet”. The root zone request to IANA has caused some discussion within the WG, as there’s no precedent for such a request.

Terry Manderson mentioned the homenet-dot draft briefly at the mic in Seoul. 

The WGLC ends this week.

Suzanne

> Begin forwarded message:
> 
> From: Ray Bellis <[email-masked]>
> Subject: [homenet] WGLC on "redact" and "homenet-dot"
> Date: November 17, 2016 at 11:27:08 PM EST
> To: HOMENET <[email-masked]>
> 
> This email commences a four week WGLC comment period on
> draft-ietf-homenet-redact and draft-ietf-homenet-dot
> 
> Please send any comments to the WG list as soon as possible.
> 
> Whilst there was a very strong hum in favour of ".homenet" vs anything
> else during the meeting, and there's some discussion of that ongoing
> here on the list - I'd like us to please keep the discussion of the
> choice of domain separate from other substantive comment about the
> drafts' contents.
> 
> thanks,
> 
> Ray
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Steve Crocker <[email-masked]>
Date: Wed, 14 Dec 2016 11:18:57 -0500

I am strongly opposed to unsecured delegations in the root zone.  No matter what the problem is, an unsecured delegation is not the answer.

Steve

> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi all,
> 
>> From: Ray Bellis <[email-masked] <mailto:[email-masked]>>
>> To: HOMENET <[email-masked] <mailto:[email-masked]>>
>> 
>> [email-masked] <mailto:[email-masked]>
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 11:36:08 -0500

Is this a matter of religious conviction, or is there some issue with
unsecured delegations in the root that you are assuming is so obvious that
you don't need to tell us about it?   :)

On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker <[email-masked]> wrote:

> I am strongly opposed to unsecured delegations in the root zone.  No
> matter what the problem is, an unsecured delegation is not the answer.
>
> Steve
>
> DNSOP participants who are interested in the special use names problem
> might want to review draft-ietf-homenet-redact (
> https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/) and
> draft-ietf-homenet-dot (https://datatracker.ietf.org/
> doc/draft-ietf-homenet-dot/) for the WGLC on them in the HOMENET wg.
>
> WGLC comments should go to the WG list, [email-masked].
>
> If you do, it will also be helpful to look at RFC 7788, which specifies
> the Home Networking Control Protocol for homenets.
>
> The redact draft is intended to remove the inadvertent reservation of
> “.home” as the default namespace for homenets in RFC 7788.
>
> The homenet-dot draft is intended to provide a request under RFC 6761 for
> “.homenet” as a special use name to serve as a default namespace for
> homenets. It also asks IANA for an unsecured delegation in the root zone to
> avoid DNSSEC validation failures for local names under “.homenet”. The root
> zone request to IANA has caused some discussion within the WG, as there’s
> no precedent for such a request.
>
> *From: *Ray Bellis <[email-masked]>
> *Subject: **[homenet] WGLC on "redact" and "homenet-dot"*
> *Date: *November 17, 2016 at 11:27:08 PM EST
> *To: *HOMENET <[email-masked]>
>

---

From: Steve Crocker <[email-masked]>
Date: Wed, 14 Dec 2016 11:59:13 -0500

The latter.  All DNS answers at all levels should be signed to assure the querier of the integrity of the answer.  This has been the goal and best practice for a very long time.  For example, it was the explicit objective of the quote substantial DNSSEC effort funded by the US Dept of Homeland Security starting in 2004.

Within ICANN, in 2009 we made it a formal requirement of all new gTLDs must be signed.  The ccTLDs are not subject to ICANN rules but they have been gradually moving toward signed status.  Most of the major ccTLDs are signed and many of the others are too.  Detailed maps are created every week by ISOC.

I will also try to contribute to the homenet mailing list.

Steve

Sent from my iPhone

> On Dec 14, 2016, at 11:36 AM, Ted Lemon <[email-masked]> wrote:
> 
> Is this a matter of religious conviction, or is there some issue with unsecured delegations in the root that you are assuming is so obvious that you don't need to tell us about it?   :)
> 
>>> DNSOP participants who are interested in the special use names problem might want to review draft-ietf-homenet-redact (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/) and draft-ietf-homenet-dot (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/) for the WGLC on them in the HOMENET wg.
>>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 12:07:20 -0500

I hope it was obvious that I was pretty confident that you actually had a
reason.   :)

The issue what what you are saying is that sometimes it is technically
correct for a name to not be validatable.   The reason we want an unsecured
delegation for .homenet is that .homenet can't be validated using the root
trust anchor, because the name is has no globally unique meaning.   So the
reason that you've given doesn't apply to this case, although I completely
agree with your reason as it applies to the case of names that are globally
unique.

On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker <[email-masked]> wrote:

> The latter.  All DNS answers at all levels should be signed to assure the
> querier of the integrity of the answer.  This has been the goal and best
> practice for a very long time.  For example, it was the explicit objective
> of the quote substantial DNSSEC effort funded by the US Dept of Homeland
> Security starting in 2004.
>
> Within ICANN, in 2009 we made it a formal requirement of all new gTLDs
> must be signed.  The ccTLDs are not subject to ICANN rules but they have
> been gradually moving toward signed status.  Most of the major ccTLDs are
> signed and many of the others are too.  Detailed maps are created every
> week by ISOC.
>

---

From: Steve Crocker <[email-masked]>
Date: Wed, 14 Dec 2016 12:21:12 -0500

If it doesn’t have a globally unique meaning, it doesn’t make sense to query the root for an answer.

What problem is trying to be solved?  I suspect whatever the problem actually is, the answer will be something other than adding an unsecured delegation to the root zone.

Steve

> On Dec 14, 2016, at 12:07 PM, Ted Lemon <[email-masked]> wrote:
> 
> I hope it was obvious that I was pretty confident that you actually had a reason.   :)
> 
> The issue what what you are saying is that sometimes it is technically correct for a name to not be validatable.   The reason we want an unsecured delegation for .homenet is that .homenet can't be validated using the root trust anchor, because the name is has no globally unique meaning.   So the reason that you've given doesn't apply to this case, although I completely agree with your reason as it applies to the case of names that are globally unique.
> 
> On Wed, Dec 14, 2016 at 11:59 AM, Steve Crocker <[email-masked] <mailto:[email-masked]>> wrote:
> On Dec 14, 2016, at 11:36 AM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Dec 14, 2016, at 11:11 AM, Suzanne Woolf <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi all,
>>> 
>>>> https://www.ietf.org/mailman/listinfo/homenet <https://www.ietf.org/mailman/listinfo/homenet>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>> 
>> 
>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 14 Dec 2016 12:23:54 -0500

On 12/14/2016 12:07 PM, Ted Lemon wrote:
> correct for a name to not be validatable.   The reason we want an 
> unsecured delegation for .homenet is that .homenet can't be validated 
> using the root trust anchor, because the name is has no globally 
> unique meaning.   So the reason that you've given doesn't apply to 
> this case, although I completely agree with your reason as it applies 
> to the case of names that are globally unique.

I went back and forth on this three times in 3 minutes "Steve's right, 
no Ted's right, no, Steve's right" before settling on "I think Steve is 
mostly right, but there may be an alternative third approach".

Here's the reasoning:   Either your home router understands .homenet or 
it doesn't.  If it doesn't, then your homenet shouldn't be using 
.homenet and any .homenet lookups to the real world should fail.  If it 
does, then it should trap .homenet queries and do with it what it will.

Doing it Steve's way removes one attack surface for non-compliant 
routers on home networks and for all the rest of the networks (e.g. 
feeding a user a URL with a .homenet name on a fake webpage).

However, I think doing it Steve's way requires a *real* TLD zone for 
.homenet, if for no other reason than to include NSEC and NSEC3 records 
indicating an empty domain.

The third way is to do no delegation from the root for .homenet and just 
ensure that that name never gets registered and published.

"If it's stupid and it works, it's not stupid".

Mike

>     The latter.  All DNS answers at all levels should be signed to
>     assure the querier of the integrity of the answer.  This has been
>     the goal and best practice for a very long time.  For example, it
>     was the explicit objective of the quote substantial DNSSEC effort
>     funded by the US Dept of Homeland Security starting in 2004.
>
>     Within ICANN, in 2009 we made it a formal requirement of all new
>     gTLDs must be signed.  The ccTLDs are not subject to ICANN rules
>     but they have been gradually moving toward signed status.  Most of
>     the major ccTLDs are signed and many of the others are too. 
>     Detailed maps are created every week by ISOC.
>
>>     Is this a matter of religious conviction, or is there some issue
>>     with unsecured delegations in the root that you are assuming is
>>     so obvious that you don't need to tell us about it?   :)
>>
>>     On Wed, Dec 14, 2016 at 11:18 AM, Steve Crocker
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         I am strongly opposed to unsecured delegations in the root
>>         zone.  No matter what the problem is, an unsecured delegation
>>         is not the answer.
>>
>>         Steve
>>
>>>         On Dec 14, 2016, at 11:11 AM, Suzanne Woolf
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>         Hi all,
>>>
>>>         DNSOP participants who are interested in the special use
>>>         names problem might want to review draft-ietf-homenet-redact
>>>         (https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/
>>>         <https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/>)
>>>         and draft-ietf-homenet-dot
>>>         (https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/
>>>         <https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/>)
>>>         for the WGLC on them in the HOMENET wg.
>>>
>>>         If you do, it will also be helpful to look at RFC 7788,
>>>         which specifies the Home Networking Control Protocol for
>>>         homenets.
>>>
>>>         The redact draft is intended to remove the inadvertent
>>>         reservation of “.home” as the default namespace for homenets
>>>         in RFC 7788.
>>>
>>>         The homenet-dot draft is intended to provide a request under
>>>         RFC 6761 for “.homenet” as a special use name to serve as a
>>>         default namespace for homenets. It also asks IANA for an
>>>         unsecured delegation in the root zone to avoid DNSSEC
>>>         validation failures for local names under “.homenet”. The
>>>         root zone request to IANA has caused some discussion within
>>>         the WG, as there’s no precedent for such a request.
>>>
>>>>         *From: *Ray Bellis <[email-masked] <mailto:[email-masked]>>
>>>>         *To: *HOMENET <[email-masked] <mailto:[email-masked]>>
>>>>
>>>>         <https://www.ietf.org/mailman/listinfo/homenet>
>>>
>>>         <https://www.ietf.org/mailman/listinfo/dnsop>
>>
>>
>>         <https://www.ietf.org/mailman/listinfo/dnsop>
>>
>>
>
>
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Dec 2016 12:24:48 -0500

Is there any way this discussion could be moved to homenet, which is where the use case originates and the WG last call is taking place?

- Ralph

> On Dec 14, 2016, at 12:21 PM, Steve Crocker <[email-masked]> wrote:
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Dec 2016 17:26:05 +0000

On 14/12/2016 17:24, Ralph Droms wrote:
> Is there any way this discussion could be moved to homenet, which is
> where the use case originates and the WG last call is taking place?

Ralph,

I think this is primarily a DNSSEC problem, and the expertise for that
is here rather than in Homenet.

Ray

---

From: Steve Crocker <[email-masked]>
Date: Wed, 14 Dec 2016 12:34:03 -0500

Mike,

A query to the root for .homenet results in a *signed* answer that .homenet does not exist.  This should suffice for the purpose you have in mind.

Ralph,

Re moving to the homenet list, I will try to send the same info there once I have time to sign up for that list.

Steve

> On Dec 14, 2016, at 12:23 PM, Michael StJohns <[email-masked]> wrote:
> 
> I went back and forth on this three times in 3 minutes "Steve's right, no Ted's right, no, Steve's right" before settling on "I think Steve is mostly right, but there may be an alternative third approach".
> 
> Here's the reasoning:   Either your home router understands .homenet or it doesn't.  If it doesn't, then your homenet shouldn't be using .homenet and any .homenet lookups to the real world should fail.  If it does, then it should trap .homenet queries and do with it what it will.
> 
> Doing it Steve's way removes one attack surface for non-compliant routers on home networks and for all the rest of the networks (e.g. feeding a user a URL with a .homenet name on a fake webpage).
> 
> However, I think doing it Steve's way requires a *real* TLD zone for .homenet, if for no other reason than to include NSEC and NSEC3 records indicating an empty domain.
> 
> The third way is to do no delegation from the root for .homenet and just ensure that that name never gets registered and published.
>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 14 Dec 2016 12:37:50 -0500

On 12/14/2016 12:34 PM, Steve Crocker wrote:
> Mike,
>
> A query to the root for .homenet results in a *signed* answer that 
> .homenet does not exist.  This should suffice for the purpose you have 
> in mind.

Yup - that's my comment:

    The third way is to do no delegation from the root for .homenet and
    just ensure that that name never gets registered and published.

>
> Ralph,
>
> Re moving to the homenet list, I will try to send the same info there 
> once I have time to sign up for that list.

Actually, I think Ray was probably more right on where this - 
specifically - should be discussed.  Once done, then Homenet needs to 
consider what to do about the guidance.

Mike

>
> Steve
>
>> On Dec 14, 2016, at 12:23 PM, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> The issue what what you are saying is that sometimes it is 
>>> technically correct for a name to not be validatable.   The reason 
>>> we want an unsecured delegation for .homenet is that .homenet can't 
>>> be validated using the root trust anchor, because the name is has no 
>>> globally unique meaning.   So the reason that you've given doesn't 
>>> apply to this case, although I completely agree with your reason as 
>>> it applies to the case of names that are globally unique.
>>
>> I went back and forth on this three times in 3 minutes "Steve's 
>> right, no Ted's right, no, Steve's right" before settling on "I think 
>> Steve is mostly right, but there may be an alternative third approach".
>>
>> Here's the reasoning:   Either your home router understands .homenet 
>> or it doesn't.  If it doesn't, then your homenet shouldn't be using 
>> .homenet and any .homenet lookups to the real world should fail.  If 
>> it does, then it should trap .homenet queries and do with it what it 
>> will.
>>
>> .homenet, if for no other reason than to include NSEC and NSEC3 
>> records indicating an empty domain.
>>
>> The third way is to do no delegation from the root for .homenet and 
>> just ensure that that name never gets registered and published.
>>
>>>     assure the querier of the integrity of the answer.  This has
>>>     been the goal and best practice for a very long time.  For
>>>     example, it was the explicit objective of the quote substantial
>>>     DNSSEC effort funded by the US Dept of Homeland Security
>>>     starting in 2004.
>>>
>>>     but they have been gradually moving toward signed status.  Most
>>>     of the major ccTLDs are signed and many of the others are too. 
>>>>     Is this a matter of religious conviction, or is there some
>>>>     issue with unsecured delegations in the root that you are
>>>>     assuming is so obvious that you don't need to tell us about it?
>>>>       :)
>>>>
>>>>         zone.  No matter what the problem is, an unsecured
>>>>         delegation is not the answer.
>>>>
>>>>         Steve
>>>>
>>>>>         reservation of “.home” as the default namespace for
>>>>>         homenets in RFC 7788.
>>>>>
>>>>>         The homenet-dot draft is intended to provide a request
>>>>>         under RFC 6761 for “.homenet” as a special use name to
>>>>>         serve as a default namespace for homenets. It also asks
>>>>>         IANA for an unsecured delegation in the root zone to avoid
>>>>>         DNSSEC validation failures for local names under
>>>>>         “.homenet”. The root zone request to IANA has caused some
>>>>>         discussion within the WG, as there’s no precedent for such
>>>>>         a request.
>>>>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 12:45:40 -0500

> What problem is trying to be solved?  I suspect whatever the problem actually is, the answer will be something other than adding an unsecured delegation to the root zone.

When considering problems, it is better to consider the problem first, rather than proposing solutions first. :)

The problem is that we (the working group) want DNSSEC validation to be as broadly enabled as makes sense.   In my opinion, this means that hosts should be doing DNSSEC validation.   However, the expectation is that they will be talking to their local caching resolver to get the information they need to do validation.   What we want is for the local resolver to be able to present a consistent picture of the homenet domain that is locally consistent and will not fail validation.   We do not want to have to specially configure resolvers—it’s not reasonable to expect end users to do this, and I don’t want to open up a security hole by setting up a way to do it automatically.   What we want is for validation on the homenet to Just Work.

We can of course in theory design a secure extension that allows DNSSEC validation to work on homenets through automatic configuration of trust anchors, but we can’t assume that all resolvers will support this functionality.   Resolution on the homenet has to work even if we are using a validator that doesn’t support special handling of trust anchors for .homenet.   And, frankly, we don’t know if we can come up with a secure way to do trust anchors on homenets even for hosts that decide to support them.   I want to think we can, but we can’t assume that we can.

So while in theory, not querying the root server would be a way to address this, not querying the root server indirectly through the cache is not an option, because we have to provide valid data from the root about .homenet.   If that valid data is a secure denial of existence for .homenet, then no name in .homenet can possibly validate.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 12:46:20 -0500

On Dec 14, 2016, at 12:23 PM, Michael StJohns <[email-masked]> wrote:
>  Either your home router understands .homenet or it doesn't.  If it doesn't, then your homenet shouldn't be using .homenet and any .homenet lookups to the real world should fail.  If it does, then it should trap .homenet queries and do with it what it will.

If the host isn’t validating, we don’t have a problem.   But the host should always be validating.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Dec 2016 14:43:36 -0500

> On Dec 14, 2016, at 12:37 PM, Michael StJohns <[email-masked]> wrote:
> 
> Actually, I think Ray was probably more right on where this - specifically - should be discussed.  Once done, then Homenet needs to consider what to do about the guidance.

On the other hand, homenet has the expertise in the specific problem space, and will ultimately need to make the decision about how to proceed.  Engagement in the discussion is likely to help the homenet WG make an informed decision.

- Ralph

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 14 Dec 2016 14:46:11 -0500

Ray,

While I can’t speak for Ralph, I also suggested that comments from DNSOP participants on these drafts should go to the HOMENET WG list, because they were input to a HOMENET WGLC.

It does seem to me that the discussion of DNSSEC, including the opposition of the chair of ICANN to an unsigned delegation in the root zone for .homenet, is input that the WG should have, but HOMENET needs to decide what to make of that input.

What’s the best way for DNS experts in DNSOP to provide input to HOMENET on these drafts in WGLC? 

thanks,
Suzanne

> On Dec 14, 2016, at 12:26 PM, Ray Bellis <[email-masked]> wrote:
> 
> 
>

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 14 Dec 2016 21:14:00 +0100

> agree with your reason as it applies to the case of names that are globally

Any reason why homenet shuld use a TLD? What is wrong with something
like homenet.arpa (or thuisnet.arpa, or bob.arpa).

	jaap

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 15:40:14 -0500

> like homenet.arpa (or thuisnet.arpa, or bob.arpa).

It’s more typing, and is not consistent with ".local".   That is to say, a reasonably intelligent and observant user with no mental model of how the DNS works would see ".local" and ".home.arpa" as very different things, when in fact the intention is that they be considered to be very similar things.

This is not an absolute requirement, obviously, but there has been a strong sentiment within the working group, from a usability perspective, to try to preserve this appearance.

It’s also been pointed out that if you google ARPA, you get a response that ARPA is a military thing.   This would probably add to the cognitive dissonance.   One way to fix that would be to create a ".lcl" or ".nuq" or something like that domain with a secure delegation that’s then handled the same way ".arpa" is, and that is explicitly designated as a place for putting non-globally-unique names that are meant to be resolved using the DNS.   But this option isn’t available to the working group, and isn’t preferred anyway.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Dec 2016 20:43:34 +0000

> like homenet.arpa (or thuisnet.arpa, or bob.arpa).

<hat partly-on>

It's not considered user-friendly enough.

The historic meaning of ARPA is considered by some to be problematic in
the consumer space that Homenet is targeting.

It's unfortunate that it's the only top-level name under IAB control.
The current expansion of the acronym to "Address and Routing Parameter
Area" is itself not a good fit for this somewhat more generic use case.

Ray

---

From: Jim Reid <[email-masked]>
Date: Wed, 14 Dec 2016 21:16:10 +0000

> On 14 Dec 2016, at 20:43, Ray Bellis <[email-masked]> wrote:
> 

So what? End users are not expected to see this string, far less care about it, are they? Surely this string is primarily, if not exclusively, for CPE firmware?

> the consumer space that Homenet is targeting.

Perhaps the way to resolve that is to tackle those misunderstandings and any FUD around them. The self-same issue was discussed ad nauseam ~15 years ago over ENUM.

IMO, the question here for the advocates of a TLD for home networks (for some definition of that term) is “what specifically can you do with .homenet (say) that you can’t do with homenet.arpa (say)?” ie What are the use case(s) and problem statement(s) that need to be addressed? And, as a logical followup, are those issues valid?

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 14 Dec 2016 22:33:48 +0100

> > like homenet.arpa (or thuisnet.arpa, or bob.arpa).

Which hat?

 > Area" is itself not a good fit for this somewhat more generic use case.

But is there a technical argument? Or is this just a well a believe
it doesn't fit perfectly. Does it really matter how the identifier
is called?

	jaap

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Dec 2016 21:48:26 +0000

On 14/12/2016 21:16, Jim Reid wrote:

> So what? End users are not expected to see this string, far less care
> about it, are they? Surely this string is primarily, if not
> exclusively, for CPE firmware?

Actually, yes, they are expected to see this thing.

It would be what would appear in their browser bar, for example, if
accessing the web UI of various on-net devices or services.

> Perhaps the way to resolve that is to tackle those misunderstandings
> and any FUD around them. The self-same issue was discussed ad nauseam
> ~15 years ago over ENUM.
> 
> IMO, the question here for the advocates of a TLD for home networks
> (for some definition of that term) is “what specifically can you do
> with .homenet (say) that you can’t do with homenet.arpa (say)?” ie
> What are the use case(s) and problem statement(s) that need to be
> addressed? And, as a logical followup, are those issues valid?

The arguments in favour of a pseudo-TLD are (AFAIK) entirely user
orientated, and not technical.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Dec 2016 21:51:11 +0000

>  > > like homenet.arpa (or thuisnet.arpa, or bob.arpa).

Sorry - Homenet WG co-chair :)

> it doesn't fit perfectly. Does it really matter how the identifier

No technical arguments, AFAICR, but user-friendliness and acceptance are
desirable criteria.

I should note that this has already been discussed ad-nauseum on the
Homenet WG list and in WG sessions.  The WG consensus was to apply via
RFC 6761 process for ".homenet", but then the insecure delegation point
was raised.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 08:55:36 +1100

In message <[email-masked]>, Michael S
> does, then it should trap .homenet queries and do with it what it will.

This isn't a issue for the router.  It is a issue for DNSSEC
validating clients of the router.

> feeding a user a URL with a .homenet name on a fake webpage).

Doing it Steve's way breaks ever DNSSEC validating client using the
home router.  There are good reasons why RFC 6303 requires insecure
delegations for all the namespaces listed in it.  It is mathematically
impossible for a homerouter to inject answers into a secured namespace
and that is what .homenet routers do.   Those same reasons are
equally applicable to .homenet.

If Steve is being honest in his convictions of wanting DNSSEC he
would be objecting to insecure delegations for .home{net}.arpa and
any other names we decide to use.

Now if you want .homenet to be secure it is possible.  This is one
possible way to do it.

We woud need to have homenet routers attempt to add a <TBD Algorithm
(e.g.  RSASHA256)> KEY record via UPDATE over TCP for <label>.homenet
and if they succeed they use <label>.homenet they domain for the
network.  <label> would be <TBD> characters randomly selected from
letters and digits.  The homenet router would then add up to <TBD>
NS records (and glue if necessary) using that KEY's private key to
delegate the zone to a hosting service / the homenet router.  The
homenet router could also add DS records via UPDATE again secured
using the KEY's private key.

Attempts to add records other than KEY records without a valid SIG(0)
record for the name would be rejected.  Attempts to remove records
without a valid SIG(0) would be rejected.  Only a single KEY record
would be permitted.

We also need to be able to garbage collect <label>.homenet so we
would allocate a new record type that indicates when the servers
for .homenet will clean up all records at <label>.homenet.  The
homenet router would update this periodically.  The maximum time
into the future would be <TBD>.  This would be cleaner than repurposing
a existing record.  The garbage collection could be driven by a
process outside of the servers that transfers the zone and sends
removal requests at the specified time with a prerequisite that the
removal record with matching time stamp exists.  This update request
would be secured using a key that is known to the .homenet
administrators.

Apart from restricting the number of records in a RRSet nameservers
exist that already have the policy knobs with the ability to do
this.  Adding the ability to specify policy like this is a couple
of hours work for a developer.  The zones contents contains all the
state for managing the delegation.

If we don't want the servers for the zone to handle the update
traffic there is already a SRV label registered for redirecting it
dedicated update servers.  Apple registered the label.  I believe
this was done so that it could send updates to Dyn's servers without
having to hard code the server names.

Now there are problems with this:
* ldhgldhgln.homenet isn't a user friendly label
* we would have to pay for servers to host the zone for $0
* a homenet only gets a name if it is online
* people would attempt to DoS the servers by adding lots entries

Mark

> --------------A28221197AC4A69387D6FCCF
> Content-Type: text/html; charset=windows-1252
> Content-Transfer-Encoding: 8bit
> 
> <html>
>   <head>
>     <meta content="text/html; charset=windows-1252"
>       http-equiv="Content-Type">
>   </head>
>   <body bgcolor="#FFFFFF" text="#000000">
>     <div class="moz-cite-prefix">On 12/14/2016 12:07 PM, Ted Lemon
>       wrote:<br>
>     </div>
>     <blockquote
> cite="mid:CAPt1N1n+PcuJ+AU-6U4TFiJvjNWz1PRNNp+y=[email-masked]"
>       type="cite">
>       <div dir="ltr">I hope it was obvious that I was pretty confident
>         that you actually had a reason.   :)
>         <div><br>
>         </div>
>         <div>The issue what what you are saying is that sometimes it is
>           technically correct for a name to not be validatable.   The
>           reason we want an unsecured delegation for .homenet is that
>           .homenet can't be validated using the root trust anchor,
>           because the name is has no globally unique meaning.   So the
>           reason that you've given doesn't apply to this case, although
>           I completely agree with your reason as it applies to the case
>           of names that are globally unique.</div>
>       </div>
>     </blockquote>
>     <br>
>     right, no Ted's right, no, Steve's right" before settling on "I
>     think Steve is mostly right, but there may be an alternative third
>     approach".<br>
>     <br>
>     will.<br>
>     <br>
>     feeding a user a URL with a .homenet name on a fake webpage).<br>
>     <br>
>     records indicating an empty domain.<br>
>     <br>
>     just ensure that that name never gets registered and published.<br>
>     <br>
>     "If it's stupid and it works, it's not stupid".<br>
>     <br>
>     Mike<br>
>     <br>
>     <blockquote
> cite="mid:CAPt1N1n+PcuJ+AU-6U4TFiJvjNWz1PRNNp+y=[email-masked]"
>       type="cite">
>       <div class="gmail_extra"><br>
>         <div class="gmail_quote">On Wed, Dec 14, 2016 at 11:59 AM, Steve
>           Crocker <span dir="ltr">&lt;<a moz-do-not-send="true"
>               href="mailto:[email-masked]" target="_blank">steve@shinkuro
> .com</a>&gt;</span>
>           wrote:<br>
>           <blockquote class="gmail_quote" style="margin:0 0 0
>             .8ex;border-left:1px #ccc solid;padding-left:1ex">
>             <div dir="auto">
>               <div>The latter.  All DNS answers at all levels should be
>                 signed to assure the querier of the integrity of the
>                 answer.  This has been the goal and best practice for a
>                 very long time.  For example, it was the explicit
>                 objective of the quote substantial DNSSEC effort funded
>                 by the US Dept of Homeland Security starting in 2004.</div>
>               <div id="m_4011273099726099435AppleMailSignature"><br>
>               </div>
>               <div id="m_4011273099726099435AppleMailSignature">Within
>                 ICANN, in 2009 we made it a formal requirement of all
>                 new gTLDs must be signed.  The ccTLDs are not subject to
>                 ICANN rules but they have been gradually moving toward
>                 signed status.  Most of the major ccTLDs are signed and
>                 many of the others are too.  Detailed maps are created
>                 every week by ISOC.</div>
>               <div id="m_4011273099726099435AppleMailSignature"><br>
>               </div>
>               <div id="m_4011273099726099435AppleMailSignature">I will
>                 also try to contribute to the homenet mailing list.</div>
>               <div id="m_4011273099726099435AppleMailSignature"><br>
>               </div>
>               <div id="m_4011273099726099435AppleMailSignature">Steve</div>
>               <div id="m_4011273099726099435AppleMailSignature"><br>
>                 Sent from my iPhone</div>
>               <div>
>                 <div class="h5">
>                   <div><br>
>                     On Dec 14, 2016, at 11:36 AM, Ted Lemon &lt;<a
>                       moz-do-not-send="true"
>                       href="mailto:[email-masked]" target="_blank">mellon@f
> ugue.com</a>&gt;
>                     wrote:<br>
>                     <br>
>                   </div>
>                   <blockquote type="cite">
>                     <div>
>                       <div dir="ltr">Is this a matter of religious
>                         conviction, or is there some issue with
>                         unsecured delegations in the root that you are
>                         assuming is so obvious that you don't need to
>                         tell us about it?   :)</div>
>                       <div class="gmail_extra"><br>
>                         <div class="gmail_quote">On Wed, Dec 14, 2016 at
>                           11:18 AM, Steve Crocker <span dir="ltr">&lt;<a
>                               moz-do-not-send="true"
>                               href="mailto:[email-masked]"
>                               target="_blank">[email-masked]</a>&gt;</spa
> n>
>                           wrote:<br>
>                           <blockquote class="gmail_quote"
>                             style="margin:0 0 0 .8ex;border-left:1px
>                             #ccc solid;padding-left:1ex">
>                             <div style="word-wrap:break-word">I am
>                               strongly opposed to unsecured delegations
>                               in the root zone.  No matter what the
>                               problem is, an unsecured delegation is not
>                               the answer.
>                               <div><br>
>                               </div>
>                               <div>Steve</div>
>                               <div><br>
>                                 <div>
>                                   <blockquote type="cite">
>                                     <div>
>                                       <div
>                                         class="m_4011273099726099435h5">
>                                         <div>On Dec 14, 2016, at 11:11
>                                           AM, Suzanne Woolf &lt;<a
>                                             moz-do-not-send="true"
>                                             href="mailto:[email-masked]
> om"
>                                             target="_blank">suzworldwide@gmai
> l.com</a>&gt;
>                                           wrote:</div>
>                                         <br
> class="m_4011273099726099435m_8089574139994213748Apple-interchange-newline">
>                                       </div>
>                                     </div>
>                                     <div>
>                                       <div>
>                                         <div
>                                           class="m_4011273099726099435h5">
>                                           <div
>                                             style="word-wrap:break-word">Hi
>                                             all,
>                                             <div><br>
>                                             </div>
>                                             <div>DNSOP participants who
>                                               are interested in the
>                                               special use names problem
>                                               might want to review
>                                               draft-ietf-homenet-redact
>                                               (<a moz-do-not-send="true"
> href="https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/"
>                                                 target="_blank">https://datat
> racker.ietf.org/<wbr>doc/draft-ietf-homenet-redact/</a><wbr>)
>                                               (<a moz-do-not-send="true"
> href="https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/"
>                                                 target="_blank">https://datat
> racker.ietf.org/<wbr>doc/draft-ietf-homenet-dot/</a>)
>                                               for the WGLC on them in
>                                               the HOMENET wg.</div>
>                                             <div><br>
>                                             </div>
>                                             <div>WGLC comments should go
>                                               to the WG list, <a
>                                                 moz-do-not-send="true"
>                                                 href="mailto:[email-masked]
> "
>                                                 target="_blank">homenet@ietf.
> org</a>.</div>
>                                             <div><br>
>                                             </div>
>                                             <div>If you do, it will also
>                                               be helpful to look at RFC
>                                               7788, which specifies the
>                                               Home Networking Control
>                                               Protocol for homenets. </div>
>                                             <div><br>
>                                             </div>
>                                             <div>The redact draft is
>                                               intended to remove the
>                                               inadvertent reservation of
>                                               “.home” as the default
>                                               namespace for homenets in
>                                               RFC 7788. </div>
>                                             <div><br>
>                                             </div>
>                                             <div>The homenet-dot draft
>                                               is intended to provide a
>                                               request under RFC 6761 for
>                                               “.homenet” as a special
>                                               use name to serve as a
>                                               default namespace for
>                                               homenets. It also asks
>                                               IANA for an unsecured
>                                               delegation in the root
>                                               zone to avoid DNSSEC
>                                               validation failures for
>                                               local names under
>                                               “.homenet”. The root zone
>                                               request to IANA has caused
>                                               some discussion within the
>                                               WG, as there’s no
>                                               precedent for such a
>                                               request.</div>
>                                             <div><br>
>                                             </div>
>                                             <div>Terry Manderson
>                                               mentioned the homenet-dot
>                                               draft briefly at the mic
>                                               in Seoul. </div>
>                                             <div><br>
>                                             </div>
>                                             <div>The WGLC ends this
>                                               week.</div>
>                                             <div><br>
>                                             </div>
>                                             <div><br>
>                                             </div>
>                                             <div>Suzanne</div>
>                                             <div>
>                                               <div><br>
>                                                 <blockquote type="cite">
>                                                   <div>Begin forwarded
>                                                     message:</div>
>                                                   <br
> class="m_4011273099726099435m_8089574139994213748Apple-interchange-newline">
>                                                   <div
> style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><sp
> an
> style="font-family:-webkit-system-font,'Helvetica
>                                                       Neue',Helvetica,sans-se
> rif"><b>From:
>                                                       </b></span><span
>                                                       style="font-family:-web
> kit-system-font,Helvetica
> Neue,Helvetica,sans-serif">Ray Bellis &lt;<a moz-do-not-send="true"
>                                                         href="mailto:ray@bell
> is.me.uk"
>                                                         target="_blank">ray@b
> ellis.me.uk</a>&gt;<br>
>                                                     </span></div>
>                                                   <div
> style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><sp
> an
> style="font-family:-webkit-system-font,'Helvetica
>                                                       Neue',Helvetica,sans-se
> rif"><b>Subject:
>                                                       </b></span><span
>                                                       style="font-family:-web
> kit-system-font,Helvetica
> Neue,Helvetica,sans-serif"><b>[homenet] WGLC on "redact" and
>                                                         "homenet-dot"</b><br>
>                                                     </span></div>
>                                                   <div
> style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><sp
> an
> style="font-family:-webkit-system-font,'Helvetica
>                                                       Neue',Helvetica,sans-se
> rif"><b>Date:
>                                                       </b></span><span
>                                                       style="font-family:-web
> kit-system-font,Helvetica
> Neue,Helvetica,sans-serif">November 17, 2016 at 11:27:08 PM EST<br>
>                                                     </span></div>
>                                                   <div
> style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><sp
> an
> style="font-family:-webkit-system-font,'Helvetica
>                                                       Neue',Helvetica,sans-se
> rif"><b>To:
>                                                       </b></span><span
>                                                       style="font-family:-web
> kit-system-font,Helvetica
> Neue,Helvetica,sans-serif">HOMENET &lt;<a moz-do-not-send="true"
>                                                         href="mailto:homenet@
> ietf.org"
>                                                         target="_blank">homen
> [email-masked]</a>&gt;<br>
>                                                     </span></div>
>                                                   <br>
>                                                   <div>This email
>                                                     commences a four
>                                                     week WGLC comment
>                                                     period on<br>
> draft-ietf-homenet-redact and draft-ietf-homenet-dot<br>
>                                                     <br>
>                                                     Please send any
>                                                     comments to the WG
>                                                     list as soon as
>                                                     possible.<br>
>                                                     <br>
>                                                     Whilst there was a
>                                                     very strong hum in
>                                                     favour of ".homenet"
>                                                     vs anything<br>
>                                                     else during the
>                                                     meeting, and there's
>                                                     some discussion of
>                                                     that ongoing<br>
>                                                     here on the list -
>                                                     I'd like us to
>                                                     please keep the
>                                                     discussion of the<br>
>                                                     choice of domain
>                                                     separate from other
>                                                     substantive comment
>                                                     about the<br>
>                                                     drafts' contents.<br>
>                                                     <br>
>                                                     thanks,<br>
>                                                     <br>
>                                                     Ray<br>
>                                                     <br>
> ______________________________<wbr>_________________<br>
>                                                     homenet mailing list<br>
>                                                     <a
>                                                       moz-do-not-send="true"
> href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
>                                                     <a
>                                                       moz-do-not-send="true"
> href="https://www.ietf.org/mailman/listinfo/homenet" target="_blank">https://
> www.ietf.org/mailman/l<wbr>istinfo/homenet</a><br>
>                                                   </div>
>                                                 </blockquote>
>                                               </div>
>                                               <br>
>                                             </div>
>                                           </div>
>                                         </div>
>                                       </div>
>                                       ______________________________<wbr>____
> _____________<br>
>                                       DNSOP mailing list<br>
>                                       <a moz-do-not-send="true"
>                                         href="mailto:[email-masked]"
>                                         target="_blank">[email-masked]</a><br
> >
>                                       <a moz-do-not-send="true"
>                                         href="https://www.ietf.org/mailman/li
> stinfo/dnsop"
>                                         target="_blank">https://www.ietf.org/
> mailman/l<wbr>istinfo/dnsop</a><br>
>                                     </div>
>                                   </blockquote>
>                                 </div>
>                                 <br>
>                               </div>
>                             </div>
>                             <br>
>                             ______________________________<wbr>______________
> ___<br>
>                             DNSOP mailing list<br>
>                             <a moz-do-not-send="true"
>                               href="mailto:[email-masked]"
>                               target="_blank">[email-masked]</a><br>
>                             <a moz-do-not-send="true"
>                               href="https://www.ietf.org/mailman/listinfo/dns
> op"
>                               rel="noreferrer" target="_blank">https://www.ie
> tf.org/mailman/l<wbr>istinfo/dnsop</a><br>
>                             <br>
>                           </blockquote>
>                         </div>
>                         <br>
>                       </div>
>                     </div>
>                   </blockquote>
>                 </div>
>               </div>
>             </div>
>           </blockquote>
>         </div>
>         <br>
>       </div>
>       <br>
>       <fieldset class="mimeAttachmentHeader"></fieldset>
>       <br>
>       <pre wrap="">_______________________________________________
> DNSOP mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]
> rg</a>
> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/
> dnsop">https://www.ietf.org/mailman/listinfo/dnsop</a>
> </pre>
>     </blockquote>
>     <p><br>
>     </p>
>   </body>
> </html>
> 
> --------------A28221197AC4A69387D6FCCF--
> 
> 
> --===============6339611341455032002==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============6339611341455032002==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2016 22:04:28 -0000

>does, then it should trap .homenet queries and do with it what it will.

But it's worse than that -- if your client software does DNSSEC
validation it needs to understand that homenet is a special case and
it's OK not to validate.  This brings us to one of the knottiest parts
of special use names, which is that they're all handled differently.
For .onion, it's generally handled in a SOCKS proxy in the
application, for .local it's handled by mDNS, and for .localhost it's
special cased in the stub client library.  (There are of course other
ways one could do it, e.g., a .onion proxy on a LAN could intercept
AAAA lookups, and return link-local addresses it serves.)

One model is that DNSSEC is so complex that applications depend on the
cache and if it sets the AD bit, you trust the result.  Another is
that memory is cheap and you put a complete DNSSEC verifier in the
application libraries, so they need to get all of the DNSSEC goop and
decide for themselves whether they believe it.

In the former model, you're right, the cache can tell virtuous lies
about .homenet addresses and there's no need to put anything in the
root.  In the latter case, you're pretty much schrod.  Since there's
no way to do a DNSSEC chain from the root to a zillion random homenet
setups, an unsigned root delegation says that an unsigned result isn't
necessarily wrong, but of course it doesn't say that it's right,
either.

This is a situation that DNSSEC wasn't set up to solve, unless you're
going to wave your hands and invent some sort of DHCP extension where
the router can hand out local trust anchors.  I realize we have RFC
3318, but I don't get the impression that this is a scenario it can
handle without implausible amounts of manual preconfiguration just
to get your mobile phone on your home wifi.

So having said all this, I agree with Steve that an unsigned delegation
is a bad idea, not because all unsigned delegations are necessarily
bad, but because this one wouldn't solve enough problems to be worth
the ugly and ambiguous precedent it'd set.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2016 22:13:25 -0000

>AAAA lookups, and return link-local addresses it serves.)

Forgot to mention: homenet is a fourth model, special cased in the
cache, which is an occasional but I think infrequent alternate
implementation for .localhost.  There's implicitly a fifth for
.example, .test, and .invalid which are expected to get a normal
NXDOMAIN.  

I expect when the next 6761 candidate comes along, it'll be handled in
yet another grotty way.

R's,
John

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Dec 2016 17:23:29 -0500

> On Dec 14, 2016, at 4:48 PM, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

I know the WG has decided that home network device names should be user-friendly, so I'll make something of a moot point..."seeing" isn't the issue, in my opinion.  I see ugly names and URLs in my browser bar all the time.  "typing" is the real issue ... any time a user has to know, remember and reproduce a name for manuaal text entry, user-friendliness is important.

- Ralph

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 11:02:56 +1100

In message <[email-masked]>, "John Levine" writes:
> special cased in the stub client library.

But it isn't.  Go read the library code.  There isn't magic for
localhost in there. The code looks in /etc/hosts before looking in
the DNS (normally) if there is a gethostbyname/getaddrinfo etc.
call.  This allows the administrator to override the DNS for specific
names on this machine for those calls.  This makes "telnet localhost"
work.  It doesn't make lots of other stuff that should work succeed.

.localhost needs the same treatment as .homenet.  It doesn't get
it today but it should for the same reason .homenet needs a insecure
delegation.

> (There are of course other

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 19:04:06 -0500

On Dec 14, 2016, at 4:16 PM, Jim Reid <[email-masked]> wrote:
> Surely this string is primarily, if not exclusively, for CPE firmware?

You know what they say about assumptions.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 19:07:17 -0500

> orientated, and not technical.

You are effectively saying that user interfaces don’t matter.   If they do matter, then getting them right is indeed a technical matter.

Diving deep into an emotional argument about this is not really appropriate.   The Homenet Working Group is considering asking for .homenet as a special-use name, and barring some clear reason why that is not what we should do, that is what we are going to try to do.   Clear reasons do not include "but you could just as well do something different."

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 19:09:09 -0500

On Dec 14, 2016, at 5:04 PM, John Levine <[email-masked]> wrote:
> it's OK not to validate.
> [etc]

That is precisely why we need an unsecured delegation.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 15 Dec 2016 00:09:34 +0000

On 15/12/2016 00:07, Ted Lemon wrote:
> On Dec 14, 2016, at 4:48 PM, Ray Bellis <[email-masked]
> <mailto:[email-masked]>> wrote:
> You are effectively saying that user interfaces don’t matter.   If they
> do matter, then getting them right is indeed a technical matter.

I meant that they are not technical w.r.t the DNS protocol itself.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 19:10:05 -0500

> I meant that they are not technical w.r.t the DNS protocol itself.

Nothing about this discussion except the need for an unsecured delegation is technical.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Dec 2016 16:43:52 -0800

> That is precisely why we need an unsecured delegation.

I agree that in the current world, an unsigned delegation is required.

I would humbly suggest that use of an AS112-like set of well-known names
and IP addresses, would be the preferred way of DOING that delegation.

A well-known address set would allow homenet-aware devices to be pre-loaded
with the address of the NS, while non-aware would learn it through the
delegation.

If it were possible to have the names be served by root servers (as a
consequence of being in the set of domains served by the root servers),
then the glue data would be signed and validate-able, which is about as
good as you can get (security-wise), while making homenet strictly local.

(Within a given homenet, the well known IP(s) could be handled via anycast
or similar mechanisms, presuming the homenet mechanisms support things like
that.)

My personal recommendation would be non-RFC-1918 well known addresses.

This ensures that for queries that leak from non-1918 space sourced
queries, that the delegation is to an address that is guaranteed to be
reachable, even if the local set-up is badly broken.

That IP would be configured to give itself as the answer to any query, and
be configured to provide (rate-limed) HTTP (wild-card) responses,
that serve up the RFC for how to set up homenet. (If that RFC doesn't
exist, that really should be next on the WG milestones.)

All roads would then lead to the answer to the question, which is, "How do
I get this stuff to work?".

Brian

PS For the DNSSEC-aware humans:

I think this exposes an unforeseen edge case, not covered in the design of
DNSSEC.

I think what would have been ideal, would have been the ability to securely
delegate to a well-known name/address, but without a secure entry point.
I.e. where parent/child NS use different RRTYPEs, and the parent NS is
signed (along with glue), and there is no DS.

The child could exist as an island of security, and have a self-signed
DNSKEY (or KSK/ZSK pair).

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 19:48:08 -0500

> work.  It doesn't make lots of other stuff that should work succeed.

I'd say that's special case, since nearly every /etc/hosts I've looked at 
only conains an entry for localhost, and perhaps a useless 255.255.255.255 
for broadcasthost.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 19:48:56 -0500

> That is precisely why we need an unsecured delegation.

Except that as the [etc] said, it doesn't really solve the problem.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 20:08:46 -0500

It solves the problem of not repudiating names in the homenet.   You have
to have a special resolver to be able to validate them.

---

From: George Michaelson <[email-masked]>
Date: Thu, 15 Dec 2016 11:16:48 +1000

Two conversations in one thread is confusing.

There is a part which is about the name as a label. in the root? not
in the root? under .arpa? which process? why? -Thats mired. I'm trying
not to re-ignite flames having covered myself in petrol some time ago.

There is a part which is 'can we do DNSSEC better' about protocol and
encoding and technology. This part interests me more right now,
because it feels tractable: we're asking questions about how DNSSEC
works, and corner-cases. It feels like we're exploring the need for
something which isn't NSEC or NSEC3 but is a public signed repudiation
of things declaring them as not being in the DNS. Which is kind-of
cool because it solves one of the other (6761) questions about how to
say 'not in the DNS' if we do it right.

The problem is we want it to work with prior code. I'm struggling to
understand how that works without a time machine.

-G

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 12:18:03 +1100

In message <CAH1iCioPZiO78j478BV7t=[email-masked]>
> I get this stuff to work?".

Why is this any better than a referral to the existing root servers
and a empty locally served .homenet zone with the previously mentioned
constraint of only enabling it when the namespace is not being
forwarded.  We do this for all the default local zones so this will
just be a extra name in the list of empty local zones that are
automatically configured.  A 5 minute job to commit to all the
branches once the name is approved.  Other vendors do similar.  The
root servers will always need to be answering for homenet/DS.  The
locally served .homenet zone will stop most of the leaks for *.homenet
at the ISP level.

If there are too many leaks after 5 years (give ISPs time to deploy
the new servers) then consider a AS112 like solution but I don't
think it will be needed.

Mark

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 20:24:40 -0500

> to have a special resolver to be able to validate them.

I'm confused -- if you need a special resolver to handle .homenet anyway, 
why does it matter what's in the root?

R's,
John

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 02:52:36 +0100

> This brings us to one of the knottiest parts of special use names, which
> is that they're all handled differently.  For .onion, it's generally
> handled in a SOCKS proxy in the application, for .local it's handled by
> mDNS, and for .localhost it's special cased in the stub client library.

Let's please not bring .onion into this discussion.  .onion is a hack with
far-reaching consequences, and one that the IETF should never have
standardised.  The less we mention .onion, the better.

.onion encodes the protocol into the hostname.  Instead of .onion, tor
should have used http+tor:// and https+tor://, which would have required
no special-casing, since an application that doesn't understand the new
scheme will return an error straight away rather than leaking .onion names
into the DNS.  (I understand why .onion was used -- it was an expedient
way to avoid the need for special-case code in the browser --, but the
tradeoff that was chosen requires special-case code in every single
freaking DNS-speaking application.  Yeah, I'm still pissed off.)

Not so with .local and .homenet.  Neither of these requires any special
code in the application.  From the point of view of the application,
.local and .homenet are just ordinary domain names that are passed to the
stub resolver, which yields a perfectly normal IP(v6) address that is then
used with ICMP, TCP, UDP, DCCP (remember that?) or whatever your favourite
transport-layer protocol happens to be.  Completely unlike .onion.

Now, granted, .local and .homenet require special casing in shared parts
of the protocol stack (.local in the stub resolver, .homenet in the
Homenet router's resolver), but this needs to be done just once in the
protocol stack, not in every single application.  Completely unlike .onion.

Sorry for the rant.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 03:06:04 +0100

> requires special-case code in every single freaking DNS-speaking
> application.  Yeah, I'm still pissed off.)

Since people seem puzzled about my rant, here's the relevant quotation
from RFC 7686:

    Applications that do not implement the Tor protocol SHOULD generate an
    error upon the use of .onion and SHOULD NOT perform a DNS lookup.

RFC 7686 updates every single DNS-using application protocol, even if it
has nothing to do with tor.  Now go and fix the FTP client you wrote in
1984, it violates RFC 7686.

-- Juliusz

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2016 02:18:31 -0000

>protocol stack, not in every single application.  Completely unlike .onion.

I think you're making unwarranted assumptions about software design
here.  On the computers I know, the stub resolver is in one shared
library and the SOCKS proxy is in another.  What's the difference?

I agree that ToR users typically use specially configured browsers
to minimize side channel leakage, but that's unrelated to the way
the the sockets work.  You can run POP3 over ToR if you want to.

The somewhat relevance to the topic at hand is that we seem to have
different mental models of the way the clients work.  If we expect the
client libraries to know that .homenet is special, it doesn't matter
what's in the root.  If we expect they don't, and all the magic is in
the router, I still don't see any solutions that aren't really ugly.
If we do the unsigned delegation that Mark wants, the validating client
can tell that the .homenet answers it's getting aren't necessarily
bogus, but it can't tell that they're authentic either.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2016 02:22:03 -0000

>1984, it violates RFC 7686.

My applications call res_query() to look up AAAA and A records,
so they don't work with .home, either.  That horse left the barn
a long time ago.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Dec 2016 18:22:42 -0800

> locally served .homenet zone will stop most of the leaks for *.homenet

It depends on perspective, and your definition of "better".

The homenet folks want zero configuration, want it to work, and don't want
to wait.

The difference between the scenarios are:
- How a non-aware resolver within a homenet (which has a correctly deployed
aware resolver) behaves
- How much infrastructure requires changes before the first improperly
deployed homenet gets any help
  - In your scenario, it never gets help, and leaks to the root until ISPs
and/or resolvers get changes deployed
  - In my scenario, the first instance of an upgraded AS112 node (with new
address being anycast) results in universal support, modulo available
capacity

If you only care about leaking, you are missing the point.

If you care about both leaking, *and* getting mixed environments to work,
*and* minimizing deployment support costs, you should be able to see why
this is better.

> the new servers) then consider a AS112 like solution but I don't

IMHO, this is mostly backwards. In this case, I think the AS112 would
probably need to be permanent.

But, in general, the fastest way of fixing the leaks is, deploy the leak
shield (AS112), then fix the leaks, then remove the leak shield when it is
no longer needed.

Waiting until the deluge has become a dribble, seems backwards.
(Plus, look how well that worked for spam.)

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 21:35:41 -0500

You would need a special resolver to _validate_ .homenet automatically
using a trust anchor published by the home network.   You do not need a
special resolver to look up names in the homenet without validation, if
there is an unsecured delegation at the root.   If there is a secure denial
of existence or a secure delegation at the root, then no validating
resolver can look up names in the homenet domain.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 21:37:38 -0500

Brian, there's no need for the complexity you are describing.   The
unsecured delegation of .homenet would just point to AS112.   Any trust
anchor bootstrapping would not involve the root at all.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 14:20:15 +1100

In message <CAH1iCir6R=[email-masked]>
> address being anycast) results in universal support, modulo available

Add this or the equivalent to each root server.

zone homenet {
	file "homenet.db";
	masters { icann's servers; };
	type slave;
};

homenet.db:
HOMENET. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016121401 1800 900 604800 86400
HOMENET. 86400 IN NS A.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS B.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS C.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS D.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS E.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS F.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS G.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS H.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS I.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS J.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS K.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS L.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS M.ROOT-SERVERS.NET.

and add the following to the root zone

HOMENET. 86400 IN NS A.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS B.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS C.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS D.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS E.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS F.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS G.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS H.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS I.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS J.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS K.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS L.ROOT-SERVERS.NET.
HOMENET. 86400 IN NS M.ROOT-SERVERS.NET.

verses

* getting new IPv4 and IPv6 address blocks for the new anycast servers.
* configuring them to serve the zone.
* getting the prefixes for these servers announced world wide.
* getting the insecure delegation into the root zone as it is still needed.

	HOMENET. 86400 IN NS SOME.NEW.SERVER.
	HOMENET. 86400 IN NS ANOTHER.NEW.SERVER.

* adding the new addresses to the every homenet router since you don't
  want to follow the delegation from the root servers.

In what world is the second senario faster or less work than the first?

Just bringing up undelegated servers for HOMENET does not help is
any way what so ever.  A homenet aware router will not talk to them
ever as it is authoritative for HOMENET or knows the servers that
are authoritative via HNCP and will direct HOMENET queries there
other than for HOMENET/DS which will be directed to the rootserver
(directly or indirectly).  If the domain advertised in via HNCP is
not HOMENET it still configures itself as authoritative for HOMENET
with a empty zone to catch leaks from roaming devices.  A non homenet
aware router will not talk to them ever as they are not delegated
too.

> *and* minimizing deployment support costs, you should be able to see why

No.  You have not shown this.

> (Plus, look how well that worked for spam.)

There is no deluge at the moment.  There should not be a deluge in
the future as HOMENET routers don't leak HOMENET lookups and HOMENET
aware name servers don't leak HOMENET queries as they self configure
to serve HOMENET.  The delay is to give time to allow ISPs to deploy
HOMENET aware servers.

This is not RFC 1918 where there were just instructions to "don't
leak".  In this case we are deploying software that actively stops
leaks by default.

Mark

> --001a11467d66e3e63d0543a920b7
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
> te">On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews <span dir=3D"ltr">&lt;<a =
> href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span=
> > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
> rder-left:1px #ccc solid;padding-left:1ex"><br>
> In message &lt;CAH1iCioPZiO78j478BV7t=3D<a href=3D"mailto:pTN9LZXQbweeBZQF2=
> [email-masked]">pTN9LZ<wbr>XQbweeBZQF2w3O1gKwx3XA@mail.<wbr>gma=
> il.com</a>&gt;<br>
> <div><div class=3D"h5">, Brian Dickson writes:<br>
> &gt;<br>
> &gt; On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon &lt;<a href=3D"mailto:mello=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt; On Dec 14, 2016, at 5:04 PM, John Levine &lt;<a href=3D"mailto:jo=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt; But it&#39;s worse than that -- if your client software does DNSS=
> EC<br>
> &gt; &gt; validation it needs to understand that homenet is a special case =
> and<br>
> &gt; &gt; it&#39;s OK not to validate.<br>
> &gt; &gt;<br>
> &gt; &gt; [etc]<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; That is precisely why we need an unsecured delegation.<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; I agree that in the current world, an unsigned delegation is required.=
> <br>
> &gt;<br>
> &gt; I would humbly suggest that use of an AS112-like set of well-known nam=
> es<br>
> &gt; and IP addresses, would be the preferred way of DOING that delegation.=
> <br>
> &gt;<br>
> &gt; A well-known address set would allow homenet-aware devices to be pre-l=
> oaded<br>
> &gt; with the address of the NS, while non-aware would learn it through the=
> <br>
> &gt; delegation.<br>
> &gt;<br>
> &gt; If it were possible to have the names be served by root servers (as a<=
> br>
> &gt; consequence of being in the set of domains served by the root servers)=
> ,<br>
> &gt; then the glue data would be signed and validate-able, which is about a=
> s<br>
> &gt; good as you can get (security-wise), while making homenet strictly loc=
> al.<br>
> &gt;<br>
> &gt; (Within a given homenet, the well known IP(s) could be handled via any=
> cast<br>
> &gt; or similar mechanisms, presuming the homenet mechanisms support things=
>  like<br>
> &gt; that.)<br>
> &gt;<br>
> &gt; My personal recommendation would be non-RFC-1918 well known addresses.=
> <br>
> &gt;<br>
> &gt; This ensures that for queries that leak from non-1918 space sourced<br=
> >
> &gt; queries, that the delegation is to an address that is guaranteed to be=
> <br>
> &gt; reachable, even if the local set-up is badly broken.<br>
> &gt;<br>
> &gt; That IP would be configured to give itself as the answer to any query,=
>  and<br>
> &gt; be configured to provide (rate-limed) HTTP (wild-card) responses,<br>
> &gt; that serve up the RFC for how to set up homenet. (If that RFC doesn&#3=
> 9;t<br>
> &gt; exist, that really should be next on the WG milestones.)<br>
> &gt;<br>
> &gt; All roads would then lead to the answer to the question, which is, &qu=
> ot;How do<br>
> &gt; I get this stuff to work?&quot;.<br>
> &gt;<br>
> &gt; Brian<br>
> <br>
> </div></div>Why is this any better than a referral to the existing root ser=
> vers<br>
> and a empty locally served .homenet zone with the previously mentioned<br>
> constraint of only enabling it when the namespace is not being<br>
> forwarded.=C2=A0 We do this for all the default local zones so this will<br=
> >
> just be a extra name in the list of empty local zones that are<br>
> automatically configured.=C2=A0 A 5 minute job to commit to all the<br>
> branches once the name is approved.=C2=A0 Other vendors do similar.=C2=A0 T=
> he<br>
> root servers will always need to be answering for homenet/DS.=C2=A0 The<br>
> locally served .homenet zone will stop most of the leaks for *.homenet<br>
> at the ISP level.<br></blockquote><div><br></div><div>It depends on perspec=
> tive, and your definition of &quot;better&quot;.</div><div><br></div><div>T=
> he homenet folks want zero configuration, want it to work, and don&#39;t wa=
> nt to wait.</div><div><br></div><div>The difference between the scenarios a=
> re:</div><div>- How a non-aware resolver within a homenet (which has a corr=
> ectly deployed aware resolver) behaves</div><div>- How much infrastructure =
> requires changes before the first improperly deployed homenet gets any help=
> </div><div>=C2=A0 - In your scenario, it never gets help, and leaks to the =
> root until ISPs and/or resolvers get changes deployed</div><div>=C2=A0 - In=
>  my scenario, the first instance of an upgraded AS112 node (with new addres=
> s being anycast) results in universal support, modulo available capacity</d=
> iv><div><br></div><div>If you only care about leaking, you are missing the =
> point.</div><div><br></div><div>If you care about both leaking, *and* getti=
> ng mixed environments to work, *and* minimizing deployment support costs, y=
> ou should be able to see why this is better.</div><div>=C2=A0</div><blockqu=
> ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
> olid;padding-left:1ex">
> <br>
> If there are too many leaks after 5 years (give ISPs time to deploy<br>
> the new servers) then consider a AS112 like solution but I don&#39;t<br>
> think it will be needed.<br></blockquote><div><br></div><div>IMHO, this is =
> mostly backwards. In this case, I think the AS112 would probably need to be=
>  permanent.</div><div><br></div><div>But, in general, the fastest way of fi=
> xing the leaks is, deploy the leak shield (AS112), then fix the leaks, then=
>  remove the leak shield when it is no longer needed.</div><div><br></div><d=
> iv>Waiting until the deluge has become a dribble, seems backwards.</div><di=
> v>(Plus, look how well that worked for spam.)</div><div><br></div><div>Bria=
> n</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
>  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> Mark<br>
> </font></span><span class=3D"im HOEnZb"><br>
> &gt; PS For the DNSSEC-aware humans:<br>
> &gt;<br>
> &gt; I think this exposes an unforeseen edge case, not covered in the desig=
> n of<br>
> &gt; DNSSEC.<br>
> &gt;<br>
> &gt; I think what would have been ideal, would have been the ability to sec=
> urely<br>
> &gt; delegate to a well-known name/address, but without a secure entry poin=
> t.<br>
> &gt; I.e. where parent/child NS use different RRTYPEs, and the parent NS is=
> <br>
> &gt; signed (along with glue), and there is no DS.<br>
> &gt;<br>
> &gt; The child could exist as an island of security, and have a self-signed=
> <br>
> &gt; DNSKEY (or KSK/ZSK pair).<br>
> </span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
> Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2=
>  9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
> =A0INTERNET: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> </div></div></blockquote></div><br></div></div>
> 
> --001a11467d66e3e63d0543a920b7--

---

From: Brian Dickson <[email-masked]>
Date: Wed, 14 Dec 2016 19:30:20 -0800

> anchor bootstrapping would not involve the root at all.

Is the intent just to have a global NXDOMAIN, provided with no DNSSEC?

That works at preventing homenet from working unless every resolver inside
the home network is homenet-aware.
(And yes, I realize as currently specified in RFC 7778, that is a
requirement.)

However, I don't believe that is only (or optimal) path for the homenet.

Their stated goal is that they want everything to work, plug-and-play.

What I'm proposing will (I believe) actually produce a working network as
long as a single resolver is homenet-aware.
It automatically gets non-homenet-aware resolvers to point at homenet-aware
resolvers (ie homenet routers), as long as the default address for homenet
routers' DNS service, is the same as the value assigned in the AS112-like
delegation.

I.e. it turns a broken hybrid of "today" networks plus a "homenet", into a
fully functional homenet with a minimum of
deployments/upgrades/replacements. It also minimizes the "broken Christmas
light" aka "missing terminator" class of problem, if any host is running
its own recursive resolver (which would then fail to properly integrate
into the homenet.)

(Also, I think having things with built-in firmware-based crappy resolvers
actually work without any patching, would be nice.)

I agree that an unsigned delegation is sufficient for non-hybrid
homenet-aware gear to provide hosts a correct homenet experience.

Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 04:49:55 +0100

> On the computers I know, the stub resolver is in one shared library and
> the SOCKS proxy is in another.  What's the difference?

The SOCKS library uses a completely different data transport (one that is
circuit-switched and layered over TCP), with very different capabilities
from the usual packet-switched transport.  Adding support for mDNS to the
stub resolver makes no change to the way the actual data is pushed around.

> You can run POP3 over ToR if you want to.

You can also run POP3 over X.25.  Shall we special-case .x25, and require
all applications to use PF_X25 instead of PF_INET6 whenever they see
a name ending in .x25?  This essentially what RFC 7686 requires for .onion.

> If we expect the client libraries to know that .homenet is special, it
> doesn't matter what's in the root.

I was under the impression that .homenet is handled entirely within the
DNS resolver of the Homenet router, which combines:

  - an authoritative DNS server for .homenet;
  - a hybrid mDNS proxy;
  - a recursive DNS resolver for the rest of the namespace.

In other words, I was assuming that we put enough Stenberg-Cheshire magic
in the Homenet router's resolver to ensure that no host changes are
necessary.  If that is not the plan, then I'd appreciate a clarification.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Dec 2016 23:01:26 -0500

A stub resolver is expected to query a caching resolver, not the root.   So
all that is required for this to work is that the resolver advertised on
the homenet claim authority for the zone, and that there be an unsecured
delegation that validates that the homenet resolver can give to the stub
resolver.   Stub resolvers that query the root themselves will fail.   This
is a feature--that behavior is broken.

On Wed, Dec 14, 2016 at 10:30 PM, Brian Dickson <
[email-masked]> wrote:

> It automatically gets non-homenet-aware resolvers to point at
> homenet-aware resolvers (ie homenet routers), as long as the default
> address for homenet routers' DNS service, is the same as the value assigned
> in the AS112-like delegation.
>
> fully functional homenet with a minimum of deployments/upgrades/replacements.
> It also minimizes the "broken Christmas light" aka "missing terminator"
> class of problem, if any host is running its own recursive resolver (which
> would then fail to properly integrate into the homenet.)
>

---

From: "John R Levine" <[email-masked]>
Date: 14 Dec 2016 23:02:32 -0500

>  - a recursive DNS resolver for the rest of the namespace.

So far so good.  The problem is a (largely hypothetical at this point) 
stub resolver that wants to do DNSSEC verification of the results the 
router gives it.

R's,
John

> from the usual packet-switched transport.

Of course, but from the point of view of a SOCKS client, either way it 
gives it a name and a port, and it gets back a two-way data stream.  If 
you don't happen to be using a web proxy or ToR, the SOCKS library does 
essentially nothing.

> Adding support for mDNS to the stub resolver makes no change to the way 
> the actual data is pushed around.

Sure it does -- the .local queries do one thing and the others do another.
Not unlike with SOCKS the .onion opens do one thing and the others do 
another.  But this is utterly tangential to the argument about resolvers 
that might want to do DNSSEC validation of .homenet results.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 15:15:38 +1100

In message <CAH1iCirFZtCWVkMqFp8Fb=[email-masked]>
> homenet-aware gear to provide hosts a correct homenet experience.

So you want the nameservers configured to serve HOMENET to advertise
a well known prefixes (IPv4 and IPv6) into the IGP and as a result
packet routing will direct HOMENET queries to those servers.

That the publically delegated to servers also use those addresses.

I suppose this helps the case of a host using interative resolution
to find the on net homenet servers.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 15:19:12 +1100

> is a feature--that behavior is broken.

Why shouldn't a iterative resolver work if we can make it work?

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Dec 2016 15:35:50 +1100

> stub resolver that wants to do DNSSEC verification of the results the 

Lots of machines already do

	forwarder { list of servers from DHCP; };
	forward only;

automatically and those servers have a DNSSEC validation enabled.
This isn't a hypothetical problem.

Mark

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Dec 2016 14:34:17 +0100

> stub resolver that wants to do DNSSEC verification of the results the

Yes, I'm following this discussion with interest.  The only bit I object
to is bringing .onion into the discussion -- .homenet is nothing like that
particular piece of bad humour.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 09:35:57 -0500

> Why shouldn't a iterative resolver work if we can make it work?

Putting an iterative resolver in a stub resolver is an attack on the DNS
infrastructure.   If you are doing it because you are testing some theory
in an experimental jig, that's perfectly fine; in that case, you are a
consenting adult, and can configure it with a special delegation for
.homenet if you need that to work.   If you are adding it to production
code that will be installed in a billion devices, you are a vandal.

---

From: Jacques Latour <[email-masked]>
Date: Thu, 15 Dec 2016 16:05:48 +0000

Ted, very clear summary, thank you.

I read the DNSSEC related homenet and dnsop comments and I don’t see how you can have DNSSEC validation for a homenet without a properly signed & delegated domain.  If we want a one shoe fits all solution then we need to have a single common domain used by all homenet, and all homenet need to use/share the same private homenet DNSSEC keys where these common keys can be validated against a common DS record inside the { homenet. home. homenet.arpa. etc } domain.

I think homenet users should have the choice of a generic homenet domain (as above, essentially an unsecure domain) or have the choice to use their own domain name for their homenet, ‘myhome.ca’ along with their own private keys and all. One domain per household. Then you could use your ‘myhome.ca’ DNSSEC infrastructure to secure your home IoT devices ☺

Where do you delegate homenet to? Advanced DNSSEC validation may check for proper delegation?

My 2 cents.

Jacques

From: homenet [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: December-12-16 10:46 AM
To: HOMENET
Subject: Re: [homenet] WGLC on "redact" and "homenet-dot"

One thing that I think the working group should be aware of, although I don't know if this awareness will change anything, is that the situation with the .homenet allocation is less simple than we would prefer: it's not really simply a matter of adding .homenet to the special use domain names registry.   The reason is that we need DNS resolution to work properly for domains under .homenet, and this has to work even if a host is doing DNSSEC validation.

At present, if you were to configure a homenet router with .home or .homenet as the local domain, this would work perfectly nicely until you turned on DNSSEC validation, at which point all the names in either hierarchy would disappear.   The reason for this is that the root zone provides proof of nonexistence for nonexistent names in that zone.

It is possible to address this problem by requesting ICANN to put an insecure delegation in the root zone.   The problem is that from a process perspective, this is a _lot_ more heavyweight than doing a special-use domain name allocation, and has no guarantee of success.   This wasn't such an issue for .onion when we did it, because .onion _wants_ a secure denial of existence--we _never_ want a .onion query to actually happen if the name has been handed to a resolver that doesn't understand .onion explicitly.   This is not true for .homenet.

There are two approaches we can take to this.   One is to proceed--ask ICANN to do the delegation and see what happens.   The other is to take the more expedient, less satisfying approach: use .home.arpa instead of .homenet.   I'm not in love with this as an end solution, but it has the advantage that the IAB controls .arpa, and so we can get an unsecure delegation right away assuming the IAB agrees.   I see no reason to think they would not.   It's a bit more typing, and there is the problem that the fourth google result for arpa is "Advanced Research Projects Agency.   But it would work, and quickly, and would keep the whole process in the family.

The other alternative is to continue with the original plan: do the special-use names registry allocation, and send a liason to ICANN asking them to do the unsecure delegation.   The downside to this approach is that we won't know whether the outcome will be success or failure for a long time, possibly several years.   And the outcome could very well be failure.   The upside is that we get the name we all want; the downside is that we are a long way down the road with no win.

I should point out that whichever way we go, we already have solved the immediate problem: we have a name that HNCP can use, the potential liability for IETF is dealt with, and our prototypes can be made to work.   So I am personally okay with either decision.   Our AD, Terry, may have more of a sense of what ICANN will do (but to some extent he really can't know, because it's up to committees within ICANN to actually make this decision).   I'm mentioning this now not to derail the process, but simply to make it really clear what our expectations should be.   The reason that this didn't come up in Seoul is that it didn't actually click for me that we had a serious problem until several of us were chatting on the way out of the room, after the working group had already decided to proceed.

On Thu, Dec 1, 2016 at 9:02 AM, Ray Bellis <[email-masked]<mailto:[email-masked]>> wrote:

On 21/11/2016 13:25, Ralph Droms wrote:
> (Updated comments on draft-ietf-homenet-dot originally posted prior to the WG last call)

Thanks Ralph.

I'd like to remind the WG that the LC is due to run until Friday
December 16th, so please anyone else with comments please get them in.

Ray

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

---

From: Bob Harold <[email-masked]>
Date: Thu, 15 Dec 2016 11:57:21 -0500

If an insecure delegation can be made in the root, then could a local trust
anchor be used by those who want their .homenet domain DNSSEC validated?
That seems easier than sharing keys or creating subdomains with nsupdate.
But I don't know much about trust anchors.

-- 
Bob Harold

---

From: Ray Bellis <[email-masked]>
Date: Thu, 15 Dec 2016 16:59:00 +0000

On 15/12/2016 16:57, Bob Harold wrote:
> If an insecure delegation can be made in the root, then could a local
> trust anchor be used by those who want their .homenet domain DNSSEC
> validated?

That's what I would have expected to happen.

> That seems easier than sharing keys or creating subdomains with
> nsupdate.  But I don't know much about trust anchors.

Shared keys would be a nightmare.

Ray

---

From: Michael StJohns <[email-masked]>
Date: Thu, 15 Dec 2016 12:10:28 -0500

> That's what I would have expected to happen.

Actually, you probably want to make a secure, delegation to an empty 
zone, so you can resolve the stuff that belongs to "." securely (e.g. 
prove that .homenet exists).  THEN you place a trust anchor specifically 
for .homenet to override the values you get from a homenet DS record in ".".

I *think* that would work with most validating resolvers.  I seem to 
remember a big argument many years ago as to whether enclosed trust 
anchors were additive (to the encloser), ignored (because they were 
enclosed), or over rode (replaced the encloser) for that branch of the 
tree but I don't remember the outcome or whether it became canon.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 12:20:53 -0500

> Where do you delegate homenet to? Advanced DNSSEC validation may check for proper delegation?  

I think we should ask ICANN to set up an unsecured delegation of .homenet to the AS112 servers.   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 homenets so that it doesn’t use the wrong key to validate.   But that’s 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.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 15 Dec 2016 12:29:48 -0500

(no hats)

> On Dec 15, 2016, at 12:20 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Dec 15, 2016, at 11:05 AM, Jacques Latour <[email-masked] <mailto:[email-masked]>> wrote:

I suspect that this discussion has shown a certain amount of confusion on the subject of exactly how to make name resolution work as implied by what we know so far about what homenets will need to do, and that it might be beneficial to resolve the question in a way that will allow for relatively easy changes later.

Given that any resolver operator who wants to configure their local resolver with special-casing for the homenet default namespace (or any other) can do so, the interesting question is what behavior is expected from the public DNS for queries on the default homenet namespace— and who has to implement it.

Which solution (.homenet or .home.arpa) is easier to refine in light of future experience seems fairly obvious to me. 

Suzanne

---

From: Steve Crocker <[email-masked]>
Date: Thu, 15 Dec 2016 14:23:00 -0500

Ted,

I am truly confused by your note.  I sense I am missing something fundamental.

See specific questions below.

Thanks,

Steve

> I think we should ask ICANN to set up an unsecured delegation of .homenet to the AS112 servers.

I don’t understand what is meant by an “unsecured delegation.”  I also don’t understand what sort of delegation you want, irrespective of whether DNSSEC is involved.

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.

That’s 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.

I suspect what’s 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.  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 aren’t occurring to me as I write this.

>   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 doesn’t 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 resolver’s public key.  This seems like a DHCP issue.

>   But that’s 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 don’t see a difference between .homenet or home.arpa in this regard.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 06:54:04 +1100

In message <CAPt1N1mwoGDuc8fn7mFd0R3cx_xQLBM3H=[email-masked]>
, Ted Lemon writes:
> --001a11411ef6886b910543b361bc
> Content-Type: text/plain; charset=UTF-8
> 
> >

Please go read STD 13 and tell me where using a iterative resolver
in a application is BANNED because it is NOT there.  Iterative
resolvers in applications are part to the data flow model for DNS.
Just because MOST application will use a stub resolver doesn't make
it REQUIRED.

There is no attack of the DNS by wanting interative resolvers to
work by default.

Mark

---

From: james woodyatt <[email-masked]>
Date: Thu, 15 Dec 2016 12:10:09 -0800

On Dec 15, 2016, at 06:35, Ted Lemon <[email-masked]> wrote:
> [Mark Andrews <[email-masked]> wrote:]
> Putting an iterative resolver in a stub resolver is an attack on the DNS infrastructure.   If you are doing it because you are testing some theory in an experimental jig, that's perfectly fine; in that case, you are a consenting adult, and can configure it with a special delegation for .homenet if you need that to work.   If you are adding it to production code that will be installed in a billion devices, you are a vandal. 

I doubt any sane home gateway vendor would do this even if the DNS infrastructure were robust enough to handle it (which, hey— I thought it was supposed to be, why isn’t it?). The reason is that too many ISPs insist on enhancing the content of the public DNS with their own private horizon stuff, so that additional services they bundle to their customers will work only on their own networks. Competition! Oh and that’s before I mention the extra featurefulness that many content delivery networks are still using for selecting servers based on the source address of the iterative DNS query instead of something more meaningful.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 15:11:20 -0500

> I don’t understand what is meant by an “unsecured delegation.”  I also don’t 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 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 securit…

Yup, understood.

> 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 registr…

It would not make sense to follow any of these processes.   This is a technical allocation under the terms of the MoU, and we don’t 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 it’s entirely reasonable for ICANN to say "no, we won’t 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 it’s 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 what’s 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 I am missing something.   I will admit to not being an expert on DNSSEC arcana, so that’s 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 aren’t occurring to me as I write this.

Yes.   It’s a big can of worms.   We won’t know precisely what’s in it unless we open it.

> 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 r…

I don’t think DHCP is the right answer, but the bottom line is that this isn’t 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.

> I don’t 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.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 07:21:11 +1100

In message <[email-masked]>, james woodyatt wr
ites:
> > Putting an iterative resolver in a stub resolver is an attack on the
> > DNS infrastructure.   If you are doing it because you are testing some
> > theory in an experimental jig, that's perfectly fine; in that case, you
> > are a consenting adult, and can configure it with a special delegation
> > for .homenet if you need that to work.   If you are adding it to
> > production code that will be installed in a billion devices, you are a
> > vandal.
>
> I doubt any sane home gateway vendor would do this even if the DNS
> infrastructure were robust enough to handle it (which, hey— I thought it
> was supposed to be, why isn’t it?). The reason is that too many ISPs
> insist on enhancing the content of the public DNS with their own private
> horizon stuff, so that additional services they bundle to their customers
> will work only on their own networks. Competition! Oh and that’s before I
> mention the extra featurefulness that many content delivery networks are
> still using for selecting servers based on the source address of the
> iterative DNS query instead of something more meaningful.

Too many people are already use third party DNS servers (Google
etc.) for ISPs to get away with this garbage anymore.  Iterative
resolvers in the CPE router just work.

The issue is more about iterative resolvers not in the CPE router.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 07:40:24 +1100

In message <[email-masked]>, Ted Lemon writes:
> > 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;
> >
> > 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.
>

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 15:51:46 -0500

> does no one any good to leave it festering.

Yup.   I think that’s the bottom line.

---

From: "John R Levine" <[email-masked]>
Date: 15 Dec 2016 15:57:18 -0500

>> Putting an iterative resolver in a stub resolver is an attack on the DNS infrastructure.

Ted might want to alert all of the BSD and linux distros that default to 
running a copy of bind or unbound answering queries on 127.0.0.1.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 16:00:20 -0500

Billions and billions of them?   How often do they query the root, do you
think, compared to a stub resolver that did recursion itself?

On Thu, Dec 15, 2016 at 3:57 PM, John R Levine <[email-masked]> wrote:

>>> infrastructure.

---

From: "John R Levine" <[email-masked]>
Date: 15 Dec 2016 16:11:37 -0500

> think, compared to a stub resolver that did recursion itself?

I have no idea, although I do know that IoT devices tend to use stripped 
down linux distros.

In any event, given that most of the root traffic is junk, I wouldn't 
think that any plausible increase in non-junk traffic would be noticable. 
Queries for TLDs cache really well.  You might want to talk to the RSSAC.

R's,
John

Regards,

---

From: Michael StJohns <[email-masked]>
Date: Thu, 15 Dec 2016 16:41:15 -0500

On 12/15/2016 3:11 PM, Ted Lemon wrote:
> On Dec 15, 2016, at 2:23 PM, Steve Crocker<[email-masked]>  wrote:

For clarity, the difference between unsecured and secured  (or as 
4033/34 call it unsigned and signed) is the presence of the DS record in 
the parent.

The problem with providing an unsecured delegation for .homenet is that 
items subsidiary to .homenet become spoofable in the wider internet and 
that's not necessarily a good thing.  It might make life easier for the 
homenet folks to use the unsecured .homenet local zone, but it might 
have adverse consequences for the non-homenet folken.

RFC6840, section 5.10 talks about how to handle nested trust anchors (in 
this case consider the global "." trust anchors and one or more local 
".homenet" trust anchors).  If ICANN does a secure delegation to a DS 
record, any 
non-homenet-compliant--but-dnssec-validating-with-root-trust-anchors end 
point or resolver will not see the .homenet zone.  In other words, you 
force a fail-secure for those systems that don't implement the Homnet 
structure.  In the Homenet-compliant case, you generate a local trust 
anchor, install it in the various machines and configure your resolution 
to use the "Accept Any Success" policy.

So the question:  fail-secure-bogus or fail-unsecured (spoofable) with 
respect to resolving .homenet on non-Homenet systems?  I'd vote for 
fail-secure and a secured/signed delegation.

I also think "secured but bogus DS records" is probably going to be a 
more acceptable use pattern for the long term for special use names - if 
for no other reason that to give us some control over the swamps.

Mike

ps - I see that at least the framework for .homenet local trust anchors 
was done: 
https://datatracker.ietf.org/doc/draft-mglt-homenet-dnssec-validator-dhc-options/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 16:55:34 -0500

On Dec 15, 2016, at 4:41 PM, Michael StJohns <[email-masked]> wrote:
> The problem with providing an unsecured delegation for .homenet is that items subsidiary to .homenet become spoofable in the wider internet and that's not necessarily a good thing.  It might make life easier for the homenet folks to use the unsecured .homenet local zone, but it might have adverse consequences for the non-homenet folken.

Until every single zone in the DNS is signed, this problem will exist.   This problem would exist if we used .home.arpa. instead of .homenet.   If we want to solve this problem, it’s going to require an extension to the DNS that provides a way to mark zones of this sort.   I would be more willing to fall on this sword if we actually got more security out of it, but I don’t think we do.

The other thing the IETF could say to the homenet working group is simply "no, you have to solve the naming hierarchy problem on homenets, and you don’t get to have an unsigned delegation at all."   But that solution would have an unreasonably large number of moving parts.   I would rather see us take a step in a direction towards things working, and then based on our wish that things be more secure, make incremental steps in that direction.   Those incremental steps do not now exist, and requiring any or all of them as a prerequisite for working service discovery on homenets is too much.

---

From: Jacques Latour <[email-masked]>
Date: Thu, 15 Dec 2016 22:04:22 +0000

This would probably a good use case for homenet to use its own DNS class, Class 2 - 0x0002 – Homenet (HN). How to implement is beyond my paygrade.
This would make homenet DNS very distinctive, which it is.

If we want to solve this problem, it’s going to require an extension to the DNS that provides a way to mark zones of this sort.   I would be more willing to fall on this sword if we actually got more security out of it, but I don’t think we do.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Dec 2016 17:50:11 -0500

It would also make it not work for any client, and it would be in direct
contradiction to advice this working group published less than a year ago.

On Thu, Dec 15, 2016 at 5:04 PM, Jacques Latour <[email-masked]>
wrote:

> This would probably a good use case for homenet to use its own DNS class,
> Class 2 - 0x0002 – Homenet (HN). How to implement is beyond my paygrade.
>
> If we want to solve this problem, it’s going to require an extension to
> the DNS that provides a way to mark zones of this sort.   I would be more
> willing to fall on this sword if we actually got more security out of it,
> but I don’t think we do.
>
>
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Dec 2016 09:56:39 +1100

In message <[email-masked]>, Ted Lemon writes:
> > homenet folks to use the unsecured .homenet local zone, but it might have
> > adverse consequences for the non-homenet folken.
>
> Until every single zone in the DNS is signed, this problem will exist.
> This problem would exist if we used .home.arpa. instead of .homenet.   If
> we want to solve this problem, it’s going to require an extension to the
> DNS that provides a way to mark zones of this sort.   I would be more

What extension?  That there is a break in the chain of trust here?
We have that.  It's called a insecure delegation.  There is NOTHING
new being asked for here.  Insecure delegations into homes exist
for RFC 1918 reverse space.  It just works.

On can do trust on first contact based on ssid or MAC for hardwired
from DHCP/RA.  While I don't like RFC 5011, you can use that to
roll trusted keys learnt this way.  I'd prefer a more CERT like
mechanism where there are date constrained records with rdata of
"<start> <end> <DS contents>" that are published along with the
DNSKEY records.  That way you don't need to be always connected
like you do with RFC 5011.  We you connect back you know whether
the TA you have learnt is expected to be valid (inside the time
window) or may have expired (after the time window) so bootstrapping
may be required again.

> The other thing the IETF could say to the homenet working group is simply
> "no, you have to solve the naming hierarchy problem on homenets, and you
> don’t get to have an unsigned delegation at all."   But that solution
> would have an unreasonably large number of moving parts.   I would rather
> see us take a step in a direction towards things working, and then based
> on our wish that things be more secure, make incremental steps in that
> direction.   Those incremental steps do not now exist, and requiring any
> or all of them as a prerequisite for working service discovery on
> homenets is too much.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 15 Dec 2016 21:27:29 -0500

> On Dec 15, 2016, at 3:51 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Dec 15, 2016, at 3:40 PM, Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:

ICYMI….

DNSOP has been considering exactly this set of issues for some time, and has adopted two relevant drafts:

* Problem statement for special use domain names: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/>

* Proposal for new top-level special use domain name as “TLD” for other special use domains: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>

Update to the roadmap from the chairs soon, but we’re looking towards consensus on the problem statement and proposals for updates/refinements to the registry policy set out in RFC 6761.

Comments/reviews on these drafts to DNSOP are welcome. 

Suzanne 
(for the chairs)

---

From: william manning <[email-masked]>
Date: Fri, 16 Dec 2016 01:46:50 -0800

actually, IoT OS platforms are mostly not stripped versions of linux, most
are purpose-built, real time OS's.  One of the more popular is RIOT.   If
you look at the attacks on these OS's, you can look at Miri, the BOT which
shows lots of packet love.
Concur that you should touch base with RSSAC before deciding to punt
traffic to the root servers to reject.  The RFC 1918 leaks were bad enough
to force the development of the AS112 infrastructure to absorb that traffic
so the roots could survive.

So we can make the delegation NOW and declare it unsigned, or we can punt
(more) traffic to the roots.
Trying to get DNSSEC validation into IoT devices requires code in the end
systems...  and

Elsewhere, Mr. O'Dell said:
"Seriously, the crapware contingent squeezes every byte out of the software
in those devices, and if somebody cannot show the incremental revenue is a
lot bigger than forcing the customer to buy a new one at some point,
there's no [dnssec] in them. Remember there is a huge difference between
inexpensive and cheap, and when consumer crapware is involved, bet on cheap
every time."

Now if we want to force the functional equivalent of renal failure on the
root servers, then by all means, don't make the delegation and hope nothing
leaks out to the public Internet.

/Wm

---

From: David Conrad <[email-masked]>
Date: Sat, 17 Dec 2016 11:25:37 -0800

I presume NSEC Aggressive Use will significantly reduce the amount of crap hitting the root servers.

Given how much capacity the root servers already have to provision to deal with that crap, I don't think a massive increase in legitimate (NSEC Aggressive Use-implementing) resolvers will move the needle significantly.

Regards,
-drc

> On Dec 15, 2016, at 1:00 PM, Ted Lemon <[email-masked]> wrote:
> 
> Billions and billions of them?   How often do they query the root, do you think, compared to a stub resolver that did recursion itself?
> 
> On Thu, Dec 15, 2016 at 3:57 PM, John R Levine <[email-masked] <mailto:[email-masked]>> wrote:
> Ted might want to alert all of the BSD and linux distros that default to running a copy of bind or unbound answering queries on 127.0.0.1.
> 
> Regards,
> John Levine, [email-masked] <mailto:[email-masked]>, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly <https://jl.ly/>
> 

Regards,
-drc
(speaking only for myself)

---

From: william manning <[email-masked]>
Date: Sat, 17 Dec 2016 11:36:48 -0800

Is there any public data to support the presumptions of excess capacity at
the roots and the impact of NSEC aggressive use on the DNS?   I know that
in the previous century, punting on operational impact by guessing about
outcomes was common.   I thought the IETF had moved away from SWAG and was
working toward a more disciplined and fact based process for making
changes.

/Wm

On Sat, Dec 17, 2016 at 11:25 AM, David Conrad <[email-masked]> wrote:

> Given how much capacity the root servers already have to provision to deal
> with that crap, I don't think a massive increase in legitimate (NSEC
> Aggressive Use-implementing) resolvers will move the needle significantly.
>
> Regards,
> -drc
>

---

From: David Conrad <[email-masked]>
Date: Sat, 17 Dec 2016 11:42:07 -0800

Bill,

On Dec 17, 2016, at 11:36 AM, william manning <[email-masked]> wrote:
> Is there any public data to support the presumptions of excess capacity at the roots and the impact of NSEC aggressive use on the DNS?

Warren provided some interesting anecdotes at the last IEPG, but I'm unaware of any formal modeling.

> I know that in the previous century, punting on operational impact by guessing about outcomes was common.   I thought the IETF had moved away from SWAG and was working toward a more disciplined and fact based process for making changes.

I make no comment on what the IETF has moved towards or away from.

Regards,
-drc

---

From: william manning <[email-masked]>
Date: Sat, 17 Dec 2016 12:17:17 -0800

David, it would seem that fact-driven processes might serve the operational
ecosystem better than SWAG, don't you agree?
Warren, do you have, even antecdotal data on the impact of aggressive NSEC
and traffic to the roots, that would inform this discussion (maybe).  At
least it would give the root operators a heads up that they were, once
again, being asked to backstop issues that should be handled elsewhere.

/Wm

On Sat, Dec 17, 2016 at 11:42 AM, David Conrad <[email-masked]> wrote:

> > Is there any public data to support the presumptions of excess capacity
> at the roots and the impact of NSEC aggressive use on the DNS?
>
> > I know that in the previous century, punting on operational impact by
> guessing about outcomes was common.   I thought the IETF had moved away
> from SWAG and was working toward a more disciplined and fact based process
> for making changes.
>

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 18 Dec 2016 16:11:41 +0100

Moin!

> crap hitting the root servers.
There are other ways of reducing the crap to the root servers (RFC 
7706). I don't think NSEC Agressive use will reduce crap a lot as if I 
remember correctly from Geoff Houstons last presentation still around 
80% of the resolver don't use DNSSEC and thus even can't implement NSEC 
Aggressive use.

However I don't think that the root servers are the problem if the end 
devices switch to recursing themselves. They are diverse enough and I 
assume the operators there have ways to increase capacity in a relative 
short time frame. A lot of the authoritative infrastructure down the 
tree just isn't ready to take the increase in traffic if we switch to an 
all endpoints recurse architecture.

I look at a lot of recursive server farms and the cache hit rate there 
are always >90% and in the mobile space usually >96%. So if we take 
these numbers that would mean a 10 fold to 25 fold increase of traffic 
to the authoritative DNS infrastructure and that doesn't even taken into 
account that a lot of cache hits result of someone else refreshing the 
cache or keeping it active.

I personally agree with Ted that recursive caches are a good thing and 
that we are not ready to switch to an end device recurses architecture. 
Sure there are a couple of Linux boxes out there that recurse themselves 
or even a couple of CPEs that do that (most though just do forwarding to 
the ISP resolver), but that is nothing compared to the billions phones 
or IOT devices on the net.

So long
-Ralf

---

From: Jim Reid <[email-masked]>
Date: Sun, 18 Dec 2016 15:32:00 +0000

> On 18 Dec 2016, at 15:11, Ralf Weber <[email-masked]> wrote:
> 
> There are other ways of reducing the crap to the root servers (RFC 7706). I don't think NSEC Agressive use will reduce crap a lot as if I remember correctly from Geoff Houstons last presentation still around 80% of the resolver don't use DNSSEC and thus even can't implement NSEC Aggressive use.

First, apologies for a meaningful and relevant Subject: header. :-)

Ralf, it’s not a question of how many resolving servers do and don’t use DNSSEC. It’s a question of how many clients that are behind them.

ISTR Geoff saying that quite a large proportion of the Internet relies on google’s or Comcast’s resolving servers. So if they were to deploy NSEC Aggressive Use, it should significantly reduce the crap query traffic going to the root.

That said, it would be good to get some data on this or model it somehow, say by using the DITL datasets. Any volunteers?

---

From: Shane Kerr <[email-masked]>
Date: Sun, 18 Dec 2016 16:43:12 +0100

Bill,

At IETF 96 in Berlin, Warren gave a presentation discussing how Google
is using this in their recursive servers. Here's the link to the
recorded video for the whole dnsop session:

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_DNSOP&chapter=chapter_1

For me the most interesting slide is around minute 25 where we see
aggressive NSEC reducing the number of queries from Google servers to
the root by over 90%.

Cheers,

--
Shane

At 2016-12-17 12:17:17 -0800

---

From: Burkov Dmitry <[email-masked]>
Date: Sun, 18 Dec 2016 18:46:40 +0300

Jim,
but you raise for me another question - if 90% will be served by google,etc - what the real value and role of the roots?

Dima
> On Dec 18, 2016, at 6:32 PM, Jim Reid <[email-masked]> wrote:
> 
>

---

From: Jim Reid <[email-masked]>
Date: Sun, 18 Dec 2016 15:52:45 +0000

> On 18 Dec 2016, at 15:46, Burkov Dmitry <[email-masked]> wrote:
> 
> Jim,

Dima, that’s a question to be answered by people well above our pay grade and we shouldn’t go down that particular rat-hole on this list.

That said, I doubt google get 90% of the Internet's query traffic. But that’s just detail. Whatever the actual number is, it will be substantial.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 21:31:13 +0100

On Thu, Dec 15, 2016 at 05:50:11PM -0500,
 Ted Lemon <[email-masked]> wrote 
 a message of 93 lines which said:

> It would also make it not work for any client, and it would be in
> direct contradiction to advice this working group published less
> than a year ago.

What did we publish on classes? If you refer to
draft-sullivan-dns-class-useless, it was never published (which is
bad).

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 21 Dec 2016 22:05:03 +0100

> draft-sullivan-dns-class-useless, it was never published (which is

As part of the IDNA discussion there is an RFC (or parts of it)
pointing out how uesless classes are.  I seem to remember it was
from the IAB and one of the authors was Klensin.

	jaa[

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 17:13:31 -0500

> draft-sullivan-dns-class-useless, it was never published (which is

That’s what I was referring to.   It was so obviously the right thing that it never occurred to me that it hadn’t been published.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Dec 2016 14:53:09 +1100

In message <[email-masked]>, Ted Lemon writes:
> That’s what I was referring to.   It was so obviously the right thing
> that it never occurred to me that it hadn’t been published.

Truely there is nothing in draft-sullivan-dns-class-useless which
says we should abandon the ability to use classes in the future.

The only thing we need to do now is to stop making type allocations
type independent by default.  Everything else is addressable in the
future when we decide we need to use a new class.

By default all new type allocations are IN only.  You need to make
the case that a type needs to be class independent or a class other
than IN.  A simple update to IANA's instructions on type allocations
would fix that.

In reality we have allocated a very small percentage of types and
having a few being class independent which didn't need to be shouldn't
be a reason to break future use of classes.

Just because we have not used classes much, because there has been
no need to date, doesn't mean that we should abandon the ability.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 22 Dec 2016 09:10:27 +0100

On Wed, Dec 21, 2016 at 10:05:03PM +0100,
 Jaap Akkerhuis <[email-masked]> wrote 

> from the IAB and one of the authors was Klensin.

I was not able to find it. Anyone has a reference?

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 22 Dec 2016 10:53:45 +0100

Stephane Bortzmeyer writes:

 > On Wed, Dec 21, 2016 at 10:05:03PM +0100, Jaap Akkerhuis
 >  <[email-masked]> wrote a message of 16 lines which said:
 > 
 > > As part of the IDNA discussion there is an RFC (or parts of it) >
 > pointing out how uesless classes are.  I seem to remember it was >

Looks like it was only a draft as well:
<https://archive.icann.org/en/meetings/stockholm/draft-klensin-i18n-newclass-00.txt>

	jaap