Subject: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

From: [email-masked]
Date: Fri, 28 Jul 2017 13:11:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking WG of the IETF.

        Title           : Special Use Domain 'home.arpa.'
        Authors         : Pierre Pfister
                          Ted Lemon
	Filename        : draft-ietf-homenet-dot-10.txt
	Pages           : 9
	Date            : 2017-07-28

Abstract:
   This document specifies the behavior that is expected from the Domain
   Name System with regard to DNS queries for names ending with
   '.home.arpa.', and designates this domain as a special-use domain
   name. 'home.arpa.' is designated for non-unique use in residential
   home networks.  Home Networking Control Protocol (HNCP) is updated to
   use the 'home.arpa.' domain instead of '.home'.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-homenet-dot-10
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-dot-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 Jul 2017 15:02:06 +1000

DNSSEC describes the delegation as "insecure".

Old:
   In addition, it's necessary, for compatibility with DNSSEC
   (Section 6), that an unsigned delegation be present for the name.
   There is an existing process for allocating names under '.arpa'
   [RFC3172].  No such process is available for requesting a similar
   delegation in the root at the request of the IETF, which does not
   administer that zone.  As a result, the use of '.home' is deprecated.

New:
   In addition, it's necessary, for compatibility with DNSSEC
   (Section 6), that an insecure delegation be present for the name.
   There is an existing process for allocating names under '.arpa'
   [RFC3172].  No such process is available for requesting a similar
   delegation in the root at the request of the IETF, which does not
   administer that zone.  As a result, the use of '.home' is deprecated.

Paragraph 5 doesn't read well and won't match reality once the
insecure delegation of home.arpa is in place.

   5.  No special processing of 'home.arpa.' is required for
       authoritative DNS server implementations.  It is possible that an
       authoritative DNS server might attempt to check the authoritative
       servers for 'home.arpa.' for a delegation beneath that name
       before answering authoritatively for such a delegated name.  In
       such a case, because the name always has only local significance
       there will be no such delegation in the 'home.arpa.' zone, and so
       the server would refuse to answer authoritatively for such a
       zone.  A server that implements this sort of check MUST be
       configurable so that either it does not do this check for the
       'home.arpa.' domain, or it ignores the results of the check.

The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
here is *important*.

Old:

7.  Delegation of 'home.arpa.'

   In order to be fully functional, there must be a delegation of
   'home.arpa.' in the '.arpa.' zone [RFC3172].  This delegation MUST
   NOT be signed, MUST NOT include a DS record, and MUST point to one or
   more black hole servers, for example 'blackhole-1.iana.org.' and
   'blackhole-2.iana.org.'.  The reason that this delegation must not be
   signed is that not signing the delegation breaks the DNSSEC chain of
   trust, which prevents a validating stub resolver from rejecting names
   published under 'home.arpa.' on a homenet name server.

New:

7.  Delegation of 'home.arpa.'

   In order to be fully functional, there must be a delegation of
   'home.arpa.' in the '.arpa.' zone [RFC3172].  This delegation
   MUST be insecure, MUST NOT include a DS record, and MUST point
   to one or more black hole servers, for example 'blackhole-1.iana.org.'
   and 'blackhole-2.iana.org.'.  The reason that this delegation
   must be insecure is that it breaks the DNSSEC chain of trust,
   which prevents a validating stub resolver from rejecting names
   published under 'home.arpa.' on a homenet name server.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 05:36:39 -0400

> The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording

Can you explain what the distinction is, and what the problem is that you see in point five?   The reason I ask is that we explicitly changed the wording from "insecure" to "not signed" because someone else said that it wasn't clear what "insecure" meant.   It seems to me that the current language is explicit and unambigious; I think this is better than being "correct."   So what is the bad outcome that might occur as a result of using the term "not signed" rather than "insecure"?

---

From: Warren Kumari <[email-masked]>
Date: Mon, 31 Jul 2017 11:42:00 -0400

On Mon, Jul 31, 2017 at 5:36 AM, Ted Lemon <[email-masked]> wrote:
> Can you explain what the distinction is, and what the problem is that you
> see in point five?   The reason I ask is that we explicitly changed the
> wording from "insecure" to "not signed" because someone else said that it
> wasn't clear what "insecure" meant.   It seems to me that the current
> language is explicit and unambigious; I think this is better than being
> "correct."   So what is the bad outcome that might occur as a result of
> using the term "not signed" rather than "insecure"?

Having recently had exactly this discussion with someone, this area is
fraught with opportunities for misunderstandings.

Let's take example.com as an example[0]. The .com zone is signed.
Example Corp hired a DNS geek, who signed the example.com zone, but
never quite got around to publishing a DS record in the parent.

There is now a signed, insecure delegation to a signed zone; the
delegation itself is signed (.com is a signed zone and so there there
is an RRSIG for the NS for example.com), but there is no DS record, so
it is insecure.

It really is an insecure delegation, not an unsigned delegation --
calling it unsigned would be confusing to many people. The person I
was discussing it with wasn't aware of the term "insecure delegation"
and assumed that it meant an "unsigned delegation", which is, um,
difficult to achieve in a non-NSEC3 OO zone...

I spend an almost infinite amount of time[1] trying to explain this
very point (to someone who understands DNSEEC) over the phone - it's
tricky to communicate without a whiteboard and / or diagram.
I ended up opening an issue on the terminology-bis document to get it
added: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/26#issuecomment-314275871

W
[0]: For the purpose of discussion, let's pretend that .COM uses NSEC,
not NSEC3 with Opt-Out.
[1]: Ok, perhaps it wasn't almost infinite, but it sure felt like it...

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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 12:04:10 -0400

> difficult to achieve in a non-NSEC3 OO zone...

Ah, I wrote that text not imagining that .arpa was signed using good old-fashioned NSEC, which was silly of me.   That said, I would rather not rely on interpretations of terminology the meaning of which isn't agreed upon.   I think it would be better to simply specify that there will be no DS record.   Does that make sense, or is there some reason why we have to say "unsigned?"

---

From: "Walter H." <[email-masked]>
Date: Mon, 31 Jul 2017 20:21:57 +0200

>     use the 'home.arpa.' domain instead of '.home'.
Just a thought of mine, would it be possible to add a section, to make 
it possible
to get official SSL certificates for these 'home.arpa.' domains (for free),
so there would not be the need of running a own PKI?

Greetings,
Walter

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 14:33:30 -0400

On Jul 31, 2017, at 2:21 PM, Walter H. <[email-masked]> wrote:
> Just a thought of mine, would it be possible to add a section, to make it possible

I don't see how that could work.   I agree that it's a problem in need of a solution, but since home.arpa wouldn't be externally visible, you couldn't use the fact that you can publish in a name in it to do the ACME authentication.

I was hoping to get IP-based certs, but it turns out that letsencrypt (probably wisely) doesn't offer them.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Aug 2017 11:41:53 +1000

> using the term "not signed" rather than "insecure"?

The delegation has *signed* NEC/NSEC3 records that prove that there
is no DS record at the delegation *and* that the delegation *exists*
unless OPTOUT is also set in the covering NSEC3 record.  The presence
of the NS bits without a SOA and DS bits in the validated NSEC/NSEC3
record proved that the child zone is insecurely delegated.  Note
this does not work if the delegation is unsigned.

All delegations from a signed zone are signed.  These is no such
thing as a unsigned delegation.  There are only secure (with signed
DS) and insecure (without DSi but with signed NSEC/NSEC3).

This is different to a unsigned delegation in a unsigned zone where
there is no proof of anything.

RFC 4033

   Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as
      insecure.

RFC 4035

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.

Then add to that "insecure delegation" is the existing term for this
type of delegation.

RFC 6063

   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
   namespaces, the zones listed above will need to be delegated as
   insecure delegations, or be within insecure zones.  This will allow
   DNSSEC validation to succeed for queries in these spaces despite not
   being answered from the delegated servers.

RFC 7719:

   Insecure delegation:  a name containing a delegation (NS RRSet), but
      lacking a DS RRSet, signifying a delegation to an unsigned child
      zone.

   Opt-out:  "The Opt-Out Flag indicates whether this NSEC3 RR may cover
      unsigned delegations."  (Quoted from [RFC5155], Section 3.1.2.1.)
      Opt-out tackles the high costs of securing a delegation to an
      insecure zone.  When using Opt-Out, names that are an insecure
      delegation (and empty non-terminals that are only derived from
      insecure delegations) don't require an NSEC3 record or its
      corresponding RRSIG records.  Opt-Out NSEC3 records are not able
      to prove or deny the existence of the insecure delegations.
      (Adapted from [RFC7129], Section 5.1)

As for point 5 the delegation for "home.arpa." will exist once IANA
adds it to the ARPA zone.  The content of the delegation won't match
but it will exist.  Note any server that performs such tests is
already broken as STD 13 requires that the child zone be setup
before the delegation is made.  I know there are DNS hosters that
require the delegation exists and list the server but they are
actually wrong to do this.  DNS delegations are make before break.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 31 Jul 2017 21:49:10 -0400

Thanks, Mark.   That was sufficient detail. :)

---

From: "Walter H." <[email-masked]>
Date: Tue, 1 Aug 2017 08:01:48 +0200

On Mon, July 31, 2017 20:33, Ted Lemon wrote:
> I don't see how that could work.

that is why my thoughts to add a section to this Draft/RFC how this will work

>  I agree that it's a problem in need of
> a solution, but since home.arpa wouldn't be externally visible,

of course, the sense of a private LAN domain name ...

> you couldn't use the fact that you can publish in a name in it
> to do the ACME authentication.

there SHOULD NOT be the ACME authentication or any neccessarity of any
other authentication, as these domain names need not be unique ...

in case you use 'teddynet.home.arpa.' and I use this domain name, too;
we wouldn't have the same x509 SSL certificate, because each of us uses
its own private key ...

why not just define the org. that hosts the ARPA TLD (IANA?), as the CA
for these domains and the root certificate as built in token to the common
browsers and/or operating systems?
there it should only be neccessary to upload the certificate request,
gicwn the '.home.arpa.' domain name, and an email address where the
certificate is sent to;
the certificate will be a wild card certificate for this .home.arpa.
domain ..

I would want this to be added as additional section to this Draft/RFC;

> (probably wisely) doesn't offer them.

IP-based is a bad idea as there is no user agent (browser) that handles
IPv6 correct in such case ...

Thanks,
Walter