[DNSOP] Comments on draft-ietf-dnsop-dnssec-validator-requirements-04

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 11 May 2023 23:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 449B9C19E111 for <dnsop@ietfa.amsl.com>; Thu, 11 May 2023 16:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id G_PMDkrP8nax for <dnsop@ietfa.amsl.com>; Thu, 11 May 2023 16:48:08 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD4BC19E106 for <dnsop@ietf.org>; Thu, 11 May 2023 16:48:08 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 07337130F10; Thu, 11 May 2023 19:48:07 -0400 (EDT)
Date: Thu, 11 May 2023 19:48:06 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <ZF1-tjjpqBsU0mmD@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lP7y-H4gTFDQRmyYHhOMeYHcupM>
Subject: [DNSOP] Comments on draft-ietf-dnsop-dnssec-validator-requirements-04
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2023 23:48:11 -0000

>              Recommendations for DNSSEC Resolvers Operators
>            draft-ietf-dnsop-dnssec-validator-requirements-04

Before I dive into some paragraph-by-paragraph details, and bury the
lede, my main high-level issue is with sections 9, primarily on
substance, but also for IMHO notably stilted and fuzzy language.

The most significant issue is that the I-D recommends at the bottom of
section 9 to cap the TTLs of all dependent RRsets by the TTLs of the DS,
KSK and ZSK records.

   >  RUNTIME:
   >   *  To limit the risks of incoherent data in the cache, it is
   >      RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of
   >      the DS, KSK and ZSK.  RRsets TTL SHOULD NOT exceed the DS, KSK or
   >      ZSK initial TTL value, that TTL SHOULD trigger delegation
   >      revalidation as described in [I-D.ietf-dnsop-ns-revalidation].
   >      TTL SHOULD NOT exceed the signature validity.

This is not necessary for correctly operated authoritative zones, that
retain "inactive" ZSKs and KSKs in the DNSKEY RRset for a few TTLs after
the keys become inactive, and likewise drop hashes of inactive KSKs from
the DS RRset only after new KSKs have been published for a sufficient

What we'd need instead of TTL capping is more akin to "revalidation"
where under normal/expected conditions, cached RRsets continue to
"enjoy" their natural TTL (as tweaked by any resolver limits).  That TLL
can for many RRsets be higher than e.g. the TTL of the parent zone DS

With "revalidation", if a DS record refreshed after TTL expiration is
(as is typically the case) identical to its previous value, or in any
case continues to establish a chain of trust to the cached DNSKEY RRset,
nothing needs to happen to the caching of the descendent records.

Similarly, DNSKEY RRset refreshes that still include the ZSK originally
used to validate a cached RRset need not have any affect on the validity
of the signed data.

The above DS and ZSK continuity conditions are expected standard
practice from the signer.  So long as these hold, validated records
should be cached for their advertised TTLs as bounded by the signed
origin TTLs and resolver cache time limits.

Resolvers *MAY* take action to revalidate cached data should abrupt
changes take place in the DS RRset (no longer building a trust path to
the cached DNSKEYs) or abrupt changes in the DNSKEY RRset (no longer
validating cached RRSIGs), but should not be expected to do so.

As resolvers gain implementation experience with this revalidation
generally, and DNSSEC trust chain revalidation specifically, and are
seen to perform revalidation safely and scalably (without thundering
herd query storms), and revalidation becomes a common implementation
feature, perhaps then we might reconsider resolver cache expectations.
We're not there yet, and in the meantime crude truncation of all TTLs to
the smaller of the DNS/DNSKEY TTLs is IMHO not a good outcome.

Moreover, this recommendation would be a barrier to shorter DS TTLs,
which are necessary to reduce mean time to recovery, making enabling
DNSSEC less daunting to risk averse authoritative zone operators.

> Abstract
>    This document clarifies the scope and responsibilities of DNSSEC
>    Resolver Operators (DRO)

O.K. so far.

>                             as well as operational recommendations that
>    DNSSEC validators operators SHOULD put in place in order to implement
>    sufficient trust that makes DNSSEC validation output accurate.

There's a missing verb in this part of the sentence.  "As well as ???"

Also: s/DNSSEC validators/DNSSEC validator/

> 1.  Introduction

>    The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC
>    validation in to their users.

Well, the purpose is to provide DNSSEC resolution.  DNSSEC validation is
a part of that, but isn't the whole.

>    By validating with DNSSEC a received Resource Record Set (RRset), the
>    resolver provides a high level of certainty that the information
>    carried by the RRset is effectively as published by the legitimate
>    owner of the RRset.


>                         The act of DNSSEC validation [RFC4033][RFC4035]
>    can be broken into two part: A _Signature Validation_ which binds the
>    RRset to a private key as well as _Trust_ in the owner of the private
>    being the legitimate owner.

This is very clumsy. Suggested:

                          The act of DNSSEC validation [RFC4033][RFC4035]
     can be broken into two parts: _Signature Validation_ which binds the
     RRset to a public key as well as establishing a _Trust Chain_
     authenticating that public key as an authorised signer for
     containing zone.

>    Signature Validation consists in checking the cryptographic signature
>    of a RRset and involves among other parameters a DNSKEY Resource
>    Record (RR) and RRSIG RR and the RRset itself.  The signature
>    validation process results in designating the owner of the RRset as
>    the owner of the corresponding private part of the public key
>    contained in the DNSKEY RR.  Cryptography provides a high level of
>    confidence in the binding to the private key.  In that sense, a rogue
>    RRset likely results from the private key being exposed or guessed --
>    as opposed to signature or key collisions for example.  As such
>    differ the confidence into the Trust to designate which DNSKEY RR is
>    legitimate.

There's no need to drag private keys into this.  Nothing in DNSSEC deals
with private keys.  We build a trust chain to a binding between a zone
name and its DNSKEY RRset which lists a set public keys that may be
used to validate RRSIGs of RRsets for which that zone is authoritative.
Questions of legitimacy or ownership, ... are not really relevant here,
we have a tree of zones, and a chain of trust to a list public keys for
each signed zone.

>    Trust implicitly assumes the private keys used to sign are not shared
>    and as such can be associated their respective owners.  The purpose
>    of Trust is to put significant confidence into designating the
>    legitimate DNSKEY RR - which also characterizes the corresponding
>    private key.  Such trust is provided by a Trust Anchor (TA), and the
>    chain of trust established between the TA and the DNSKEY RR.  The
>    chain of trust is obtained by recursively validating the DNSKEY RRs.

This and much of the introductory material below is IMHO an unnecessary

>    Once accurately validated the RRset is assumed to be accurately
>    validated and trusted during the time indicated by its TTL.

This is the property that is expected to from the signer, and should not
be undone in Section 9.

> 5.  Recommendations Categories

>    A DRO needs to be able to enable DNSSEC validation with sufficient
>    confidence they will not be held responsible in case their resolver
>    does not validate the DNSSEC response.

I don't think that questions of liability are appropriate here.

>    The minimization of these risks is provided by setting automated
>    procedures, when a resolver is started or while it is operating, as
>    well as some on-demand operations that enable the DRO to perform a
>    specific operation.  The recommendations do not come with the same
>    level of recommendations and some are likely to be required.
>    Others are optional and may be followed by more advanced DROs.  It
>    is up to the DRO to determine their applicability.
>    Regarding recommendations on the behavior of the resolver, some
>    recommendations may already be applied by default by the operated
>    resolver software, in which case the DRO does not have to perform any
>    action.  Some recommendations may require to be activated via
>    configuration by the DRO.  Some recommendations may simply not be
>    provided by the operated software, in which case we recommend the DRO
>    to contact the software vendor for further discussion.

The above is but one example of fuzzy language that is best avoided.

The document IMHO needs some overall editorial attention.


>    *  To limit the risks of incoherent data in the cache, it is
>       RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of
>       the DS, KSK and ZSK.  RRsets TTL SHOULD NOT exceed the DS, KSK or
>       ZSK initial TTL value, that TTL SHOULD trigger delegation
>       revalidation as described in [I-D.ietf-dnsop-ns-revalidation].
>       TTL SHOULD NOT exceed the signature validity.

> 11.  Cryptography Deprecation Recommendations

>    STARTUP: * DRO MUST ensure recent software releases that comply with
>    the most recent cryptographic guidances are being used


>    *  A DRO SHOULD regularly request and monitor the signature scheme
>       supported by an authoritative server.

What does this mean?

>    *  A DRO SHOULD report a "Unsupported DNSKEY Algorithm" as defined in
>       [RFC8914] when a deprecated algorithm is used for validation.

How?  To whom?

>    One inconvenient to such strategy is that it does not let one DRO to
>    take advantage of more recent cryptographic.  While currently not
>    being widely used, a DRO MAY share information with authoritative
>    server in the hope that future deployment of authoritative servers
>    will be able to leverage it.  [RFC6975] provides the ability for a
>    DNSSEC validator to announce an authoritative server the supported
>    signature schemes.  However, a DNSSEC validator is not able to
>    determine other than by requesting and monitoring DNSKEY RRsets as
>    well as RRSIG.  These RRsets are received by enabling DNSSEC
>    validation by default which is obviously the case for DNSSEC
>    validator.

This looks like a poor translation from something other than English...
Unclear where this is going.