Subject: Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 May 2018 12:57:20 -0400

> On Apr 28, 2018, at 1:28 AM, Viktor Dukhovni <[email-masked]> wrote:
> 
> So at this point I think we understand each other, and the issue comes down to whether it is appropriate for the registry to automatically turn on DS records for the first time for a domain which is substantively operationally deficient at the time its CDS records are encountered.
> 
> I think that garbage-in/garbage-out is not only a disservice to the domain's owner, but more importantly it poisons the ecosystem for everyone else.
> 
> If turning on DNSSEC validation in your resolver stops email delivery to a bunch of domains, or breaks all access to the domain's data, whom exactly is the registry helping by enabling DNSSEC for a substantially broken domain.
> 
> Think of this as anti-pollution environmental regulation.

I see a new version -05, with (so far) the Section 3.4 acceptance text
unchanged. I strongly feel broken DNSSEC adoption is much worse than no
DNSSEC adoption, it not only has operational impact on the target domain,
but also creates strong disincentives to enabling validation in resolvers.

Therefore, if at all possible, broken implementations should not have their
DS records published, and all reasonable effort should be made to detect
known forms of breakage before inflicting such breakage on the world at
large.

For example, nazwa.pl has recently signed a bunch of domains with lame
wildcard NS records under the zone apex.  This breaks denial of existence
for all child domains, including TLSA lookups, and therefore breaks email
delivery to the newly signed domains.  This is easily detected, and such
detection should be part of acceptance criteria for having DS records
published.  Yes, some domains will introduce breakage after the fact,
but we can and should avoid it at inception.

$ grep nazwa broken | ... | xargs -n1 unbound-host -D -t tlsa
validation failure <_25._tcp.andyandmag.pl. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.fruty.pl. TLSA IN>: nodata proof failed from 85.128.128.10
validation failure <_25._tcp.funit.com.pl. TLSA IN>: nodata proof failed from 195.238.185.146
validation failure <_25._tcp.informica.org. TLSA IN>: nodata proof failed from 195.238.185.146
validation failure <_25._tcp.vitacard.pl. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.sjedrzejewski.pl. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.centrumuslugszklarskich.com. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.ts3priv.pl. TLSA IN>: nodata proof failed from 195.238.185.146

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 15 May 2018 14:29:05 -0400

In article <[email-masked]> you write:
>delivery to the newly signed domains.

I think you will find that attempts to legislate against being stupid
do not generally turn out well.  It makes sense to check for mistakes
that might screw up the upper level name server like an invalid
algorithm number, but if they want to shoot themselves in the foot,
there's not much we can do about that.

There's no way to make a list of every possible stupid thing that
someone might do, so I wouldn't try.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 May 2018 14:48:17 -0400

> On May 15, 2018, at 2:29 PM, John Levine <[email-masked]> wrote:
> 

Some of the more subtle, but still very important failure modes
are not obvious unless *tested*.  It is would be a disservice to
the ecosystem to blindly turn on only partly working DNSSEC which
is actually broken in important ways.

Section 3.4 says:

   The Registration Entity, upon receiving a signal or detecting through
   polling that the child desires to have its delegation updated, SHOULD
   run a series of tests to ensure that updating the parent zone will
   not create or exacerbate any problems with the child zone.  The basic
   tests SHOULD include: [...]

And while we can't enumerate all possible breakage, there are clear
mistakes that are comparatively common now, and which would become
much more prevalent if enrollment is made easier with no due care to
ensure that we're not adding to the problems.

   * Incomplete NSEC chains that break denial of existence of
     the TLSA records of any explicit (or implicit zone apex)
     MX hosts.

   * SOA signatures that are invalid (typically modified after signing)

   * RRtype-based query filtering that drops TLSA/CAA/... queries.

   * ... and a few more ...

The above are not made-up hypotheticals, they are actually observed in
sufficient numbers to establish a pattern of likely failure modes that
need to be tested.  I have around ~200 samples that provide strong evidence
of the most common failure modes.

We can perhaps quibble over which failures might be ignored, but it
would be irresponsible and counter-productive to ignore them all.

-- 
-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 15 May 2018 15:57:19 -0400

>is actually broken in important ways.

I think it's a swell idea to offer people DNSSEC testing services but
it's hopeless to conflate it with key rotation.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 May 2018 16:11:18 -0400

> On May 15, 2018, at 3:57 PM, John Levine <[email-masked]> wrote:
> 

I completely agree with you on key rotation, once the zone has already
been operating signed.  But the document also covers enrollment:

   This document describes a simple protocol that allows a third party
   DNS operator to: establish the initial chain of trust (bootstrap
                    -----------------------------------------------
   DNSSEC) for a delegation; update DS records for a delegation; and,
   ------------------------
   remove DS records from a secure delegation.  The DNS operator may do
   these things in a trusted manner, without involving the Registrant
   for each operation.  This same protocol can be used by Registrants to
   maintain their own domains if they wish.

It is at the time of initial enrollment that I'd like to propose greater
due diligence.

-- 
	Viktor.

---

From: Jacques Latour <[email-masked]>
Date: Wed, 16 May 2018 18:38:17 +0000

The intent of the document at bootstrap is for the parent to perform sufficient tests to ensure they are conformable in bootstrapping the chain of trust, I agree with you that these tests and other could be performed by the parent to ensure the child/DNS Operator is "well behaved" and/or has "good DNSSEC hygiene".

I think defining the criteria for good DNSSEC hygiene is not in scope for this document, but this document could certainly reference something like https://tools.ietf.org/html/draft-wallstrom-dnsop-dns-delegation-requirements-03  with your details in section 8 "DNSSEC Requirements".

Also, I'm thinking at registration time to check immediately if the newly domain is suitable for DNSSEC bootstrapping, meaning the domain has a proper CDS or CDNSKEY and has good hygiene and all, so that when we publish the zone file with that new domain the DS record is included right away.  Any issues with that?

-----Original Message-----
From: DNSOP <[email-masked]> On Behalf Of Viktor Dukhovni
Sent: May 15, 2018 4:11 PM
To: dnsop <[email-masked]>
Subject: Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

-- 
	Viktor.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 May 2018 14:51:10 -0400

> On May 16, 2018, at 2:38 PM, Jacques Latour <[email-masked]> wrote:
> 

I am not a stickler for the means, so long as we achieve the same ends.
That is, provided the DNSSEC hygiene is somehow taken into account at
registration time, if this document points at some other document, that
may be OK.  My concern is only that not enough of the DANE-impacting
hygiene requirements may yet be written down.

I can make a list...  Should it go in this draft, or should I work with
Patrick Wallstrom to flesh out that draft?  Will this draft reference
the other one?

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 16 May 2018 19:12:17 -0400

On 16 May 2018 at 14:51, Viktor Dukhovni <[email-masked]> wrote:

> General DNSSEC hygeine is out of scope for this draft, so better that you
work with Patrick.  The draft already references
draft-wallstrom-dnsop-dns-delegation-requirements in the bootstrapping
section.

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 17 May 2018 16:20:27 -0400

> but also creates strong disincentives to enabling validation in resolvers.

Apologies.. I missed this comment in the thread when I went through it
earlier.

-05 was basically just a keepalive, since the draft had expired while I was
unable to keep up with IETF work over the winter.  The authors have a stack
of changes pending, some of which we're still discussing, and an -06 will
be out when we finish working through the backlog.

That said, we don't have any significant changes in mind for 3.4 that I
think are likely to make you happy.  As mentioned elsewhere previously,
general delegation hygiene and general DNSSEC hygiene rules belong
somewhere other than this draft.