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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ted Lemon writes:
> On Jul 31, 2017, at 1:02 AM, Mark Andrews <[e-mail]> wrote:
> > The delegatation is INSECURE and SIGNED not UNSIGNED.  The wording
> > here is *important*.
>
> 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"?

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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]