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

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 Apr 2018 12:54:04 -0400

A number of checks are listed in:

  https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-04#section-3.4

that are intended to make sure a domain is ready for DNSSEC.

As I've been the DNSSEC and DANE implementations at now ~5.8 million domains, I'd like to suggest some additional checks:

     o  ensuring that the SOA record RRset is correctly signed, unlike:

          http://dnsviz.net/d/_25._tcp.mx1.techtrack.gov/dnssec/

        which is always incremented by 1 *after* the zone is signed!

     o  ensuring the NS RRset at the zone apex matches the glue RRs
        at the parent zone

     o  Verifying that TLSA lookups are NOT blocked and denial of
        existence works by querying for:

	   _25._tcp.<nonce>.example.net. IN TLSA ?

        and verifying the NXDomain, NODATA, or (very rarely) wildcard
        TLSA records against the implied DNSKEYs.  The nonce can be some
        random hex string of 8 or more bytes, that is unlikely to be an
        actual name in the zone.

      o Do the above for all IPv4 and IPv6 addresses of all the nameservers,
        as some misconfigured firewalls block unexpected RR types for just
        IPv4 or just IPv6.

      o A similar probe for CAA records is likely appropriate, Let's Encrypt
        runs into CAA lookup issues for a non-negligible fraction of domains.

      o Check that if the zone uses RSA, the KSK and ZSK are at least 1280
        bits and at most 2048 bits.  This may be controversial, but for new
        deployments RSA <= 1024 bits is widely considered too weak, and RSA
        with more than 2048 bits creates signatures that are often too large
        for reliable UDP transport.

      o Check that if the zone uses NSEC3 the NSEC3PARAM iteration count is
        at most 150 (regardless of RSA key size).  Larger iteration counts
        are both inefficient and fragile in the face of algorithm rollovers.
        The optimal value is 0 (performs one round of SHA1, which is enough to
        deter casual zone walking).  The most popular value is 1, which is
        very likely because it is slightly unclear whether 0 means no hash
        or (as is the case) just one initial hash.  So hats off to the
        operations that chose 1, they understand that the count should be
        low, and are careful to avoid edge cases.

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 14 Apr 2018 16:26:20 -0400

On 14 April 2018 at 12:54, Viktor Dukhovni <[email-masked]> wrote:

> As I've been the DNSSEC and DANE implementations at now ~5.8 million
> domains, I'd like to suggest some additional checks:
>

Thanks for the review Viktor. We haven't had many DNS people respond to the
draft.. I've been considering mentioning it in DNSOP, but was going to wait
until several pending changes are in the doc and -05 is out (hopefully in
the next week or two, time permitting).

>         which is always incremented by 1 *after* the zone is signed!

I believe this is already covered by the first point: "checks that the
child zone is is properly signed as per the Registration Entity and parent
DNSSEC policies".  Although, we could add some example RRsets that should
be examined for correct signatures.

>         runs into CAA lookup issues for a non-negligible fraction of

These are getting into name server quality checks, and not security checks,
which is the point of the acceptance testing.  I don't agree that these
should be part of this document.

>         for reliable UDP transport.

While this is probably a reasonable thing to do, a registration mechanism
documented in REGEXT is not the place to do this.  I think if DNSOP wants
such advice in a standard there should be a BCP document out of DNSOP that
defines it.

>         low, and are careful to avoid edge cases.

Again, I think this is out of scope of a document standardizing a
registration mechanism.  Besides which, there are operators out there who
deliberately have a low iteration count because they don't care about zone
walking, and are only using NSEC3 for the opt-out capability.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 Apr 2018 17:05:26 -0400

> On Apr 14, 2018, at 4:26 PM, Matthew Pounsett <[email-masked]> wrote:
> 
> These are getting into name server quality checks, and not security checks, which is the point of the acceptance testing.  I don't agree that these should be part of this document.

If the registry operator is going to automatically upgrade previously insecure delegations to DNSSEC, then due diligence to make sure that this is not going to cause outages is advisable.  Once a domain is signed, TLSA and CAA lookups must succeed, or the domain may no longer receive email from DANE-enabled sending MTAs, or be able to obtain certificates from their CA, ...

So I rather strongly feel that appropriate quality checks should be in place, to protect both the registrant and the registry (dealing with fallout from outages is best avoided).

> While this is probably a reasonable thing to do, a registration mechanism documented in REGEXT is not the place to do this.  I think if DNSOP wants such advice in a standard there should be a BCP document out of DNSOP that defines it.

Yes, this is a point for discussion.  Still I think it would be bad to, for example, introduce more domains with 512-bit RSA keys, or perhaps even accept 1024-bit RSA
keys.  There are many domains with 1536-bit KSKs and 1280-bit ZSKs, these are I
think well chosen, though ECDSA P-256 (algorithm 13) is looking increasingly like
an even better choice at present.

Given that 1024-bit RSA is considered past its use-by these days, perhaps limiting
automated upgrades to DNSSEC only to stronger keys is a good idea???

> Again, I think this is out of scope of a document standardizing a registration mechanism.  Besides which, there are operators out there who deliberately have a low iteration count because they don't care about zone walking, and are only using NSEC3 for the opt-out capability.

Here you misunderstood my point, I am suggesting a MAXIMUM of 150 and recommending
0 or 1, precisely because opt-out is mostly all that NSEC3 is useful for, but one
or two rounds of SHA deter "casual" zone walking.

You may not have seen my posts to dns-operations and this list about the issues
with iteration counts that exceed 150.  The tl;dr version is don't do that.
Catching mistakes at registration time is our best opportunity to maintain the
hygiene of the ecosystem.

-- 
	Viktor.

---

From: Matthew Pounsett <[email-masked]>
Date: Fri, 27 Apr 2018 15:23:52 -0400

On 14 April 2018 at 17:05, Viktor Dukhovni <[email-masked]> wrote:

> > These are getting into name server quality checks, and not security
> checks, which is the point of the acceptance testing.  I don't agree that
> these should be part of this document.
>
> If the registry operator is going to automatically upgrade previously
> insecure delegations to DNSSEC, then due diligence to make sure that this
> is not going to cause outages is advisable.  Once a domain is signed, TLSA
> and CAA lookups must succeed, or the domain may no longer receive email
> from DANE-enabled sending MTAs, or be able to obtain certificates from
> their CA, ...
>
> So I rather strongly feel that appropriate quality checks should be in
> place, to protect both the registrant and the registry (dealing with
> fallout from outages is best avoided).
>

Except that those are standard DNSSEC operations best practices, not even
limited to CDS use, let alone a REST protocol designed for signalling that
CDS should be scanned.  Perhaps others can speak up about the applicability
here, but I feel rather strongly that general operations best practices
shouldn't be defined in a document limited to one corner case.  That risks
the advice case either not being applied elsewhere, because it's not in a
general operations document and therefore not seen, or worse contradicting
what goes into a general operations document.

The security checks in this draft are there to help ensure that the parent
can trust the update request.  I believe going further than that is out of
scope.

I think if you want there to be guidance that parents should check on the
quality of the child operations that should
1) come from DNSOP, not REGEX, and
2) be in a document about general DNSSEC operations.

We currently ref out to draft-wallstrom-dnsop-dns-delegation-requirements
in that section (we're hoping that draft continues to go somewhere so we
don't have to import too much of its text directly, although it has been
expired for a year now).  You might want to submit some text there.. or
angle for something that updates (or is a -ter for) RFC6781.

> >
> > While this is probably a reasonable thing to do, a registration
> mechanism documented in REGEXT is not the place to do this.  I think if
> DNSOP wants such advice in a standard there should be a BCP document out of
> DNSOP that defines it.
>
> Yes, this is a point for discussion.  Still I think it would be bad to,
> for example, introduce more domains with 512-bit RSA keys, or perhaps even
> accept 1024-bit RSA

But again, that's a general operations issue, and not one limited to this
signalling mechanism.

> or two rounds of SHA deter "casual" zone walking.

Yes, for some reason I got your intent backwards.  I still think it's out
of scope though... an iteration count higher than 150 does not constitute a
trustworthiness problem for the parent.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Apr 2018 01:28:16 -0400

> On Apr 27, 2018, at 3:23 PM, Matthew Pounsett <[email-masked]> wrote:
> 
> Except that those are standard DNSSEC operations best practices, not even limited to CDS use, let alone a REST protocol designed for signalling that CDS should be scanned.  Perhaps others can speak up about the applicability here, but I feel rather strongly that general operations best practices shouldn't be defined in a document limited to one corner case.  That risks the advice case either not being applied elsewhere, because it's not in a general operations document and therefore not seen, or worse contradicting what goes into a general operations document.
> 
> The security checks in this draft are there to help ensure that the parent can trust the update request.  I believe going further than that is out of scope.

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.

-- 
	Viktor.