Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

Daniel Migault <mglt.ietf@gmail.com> Wed, 17 May 2023 20:01 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B79FC15C520 for <dnsop@ietfa.amsl.com>; Wed, 17 May 2023 13:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YclnmiKmzkY for <dnsop@ietfa.amsl.com>; Wed, 17 May 2023 13:01:20 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 0A7DFC14F75F for <dnsop@ietf.org>; Wed, 17 May 2023 13:01:20 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-52cb78647ecso793601a12.1 for <dnsop@ietf.org>; Wed, 17 May 2023 13:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684353679; x=1686945679; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=6OjsyH1NgS3yCcIJIDeSaeSh2GmTzdF/apXKPR7exh8=; b=rAlYv6dxA/uPsVIODKx5ySrGrfbIk4iVuwSv0eYT6g+wm41+Y3wrcb+JUZgjxjiLRW t2cvJ7NSA45dm9i23NbwV/wZN0rkI3UtnE4V3XPrEhK7VMgewoYNteW9KAzBGmQgJiPm HS2Uaf6yvuJdtlrQLAVB7b2h8LQ19LNUssS2eD7+humCL58a6dihftTUClO7ypF8FY3r bPZWJynNozV7oxWDeAj1f5JDNCvJrXTcc+y/TFDusKyIMb0AEfXWtWjGh3smcYdCoUKd KSCjHDZcGZSPgf+VOmNRr9GPs3tjsU+Q5m+Ldm0484jiBY3Jj7spcTfAqp8NRrKC3jXR +thQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684353679; x=1686945679; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6OjsyH1NgS3yCcIJIDeSaeSh2GmTzdF/apXKPR7exh8=; b=UxvMK2ltMOQRrPxFDVS1RFPDywXyv5549LfpFXZnESu97ssRjDY984JIWf38qrYntt C+f+jrr8X47TrHGuzQSEdVGmQCx9YieVQf+KAYtf3FDLDfHG18z77R7UL2uiHZtJ7pxd zxCYUBs+7R7iYA5uAbC5ULpwr8fdzhyj8MpcxQMx5zYUh+xYYYGj5rvFZuT2MJGaUlRD xbTXtAac0JWFKITP9ul8RGLdBRPuhT4iqSD/Yd4JFO1OcXPWJT/7RqBD4usT9Vrgxw0C zIX7pl4uiVn4Ghvz2Fe25Tc3qFFgdl4rd9cwXFv85VTJuJaTKVEgKFM3Sn4w3S64IF5p FlOg==
X-Gm-Message-State: AC+VfDxoQck4x5F/EX7GptR65/xUs6GF4Pc1+G0xeebTwzBKac9uiqVN Z+/bB34+sGrrYBYr7Jyb0Tn+a4S3E1Y2mt3479ell9VegYc=
X-Google-Smtp-Source: ACHHUZ5KV9gl3d17TLqJ1dDzjZI6WZg6hGMrSlZKJ9A+e4uW9j/6B3FjRPur0IxDoDo7vexNjUW7PKVEygJxqzTP4nA=
X-Received: by 2002:a05:6a20:1448:b0:105:55a7:d5ff with SMTP id a8-20020a056a20144800b0010555a7d5ffmr18755080pzi.28.1684353678884; Wed, 17 May 2023 13:01:18 -0700 (PDT)
MIME-Version: 1.0
References: <CADyWQ+FwRaSdpSWXBDqCG9ZPNPiG4pGUx37PVtExbqVPr5ZfmA@mail.gmail.com> <ZF6rFlfM7LKObUnQ@straasha.imrryr.org>
In-Reply-To: <ZF6rFlfM7LKObUnQ@straasha.imrryr.org>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 17 May 2023 16:01:06 -0400
Message-ID: <CADZyTkn21Z4weUYqmWn1B7_8RnKxd08qnRtDb57MZGgYuASgvA@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b4d27f05fbe92658"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WReWN98g7-f9hI-RnJ_iX_2stPU>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
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: Wed, 17 May 2023 20:01:21 -0000

Hi Viktor,

Thanks for the feedbacks. Please see my comment/responses below.

Yours,
Daniel



On Fri, May 12, 2023 at 5:10 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Wed, Oct 19, 2022 at 03:21:27PM -0400, Tim Wicinski wrote:
>
> > This starts a Working Group Last Call for
> > draft-ietf-dnsop-dnssec-validator-requirements
> >
> > Current versions of the draft is available here:
> >
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
> >
> > The Current Intended Status of this document is: Informational
> >
> > Please review the draft and offer relevant comments.
> > If this does not seem appropriate please speak out.
> > If someone feels the document is *not* ready for publication, please
> speak
> > out with your reasons.
> >
> > This starts a two week Working Group Last Call process, and ends on:  2
> > November 2022
>
> Repost of my belated comments in the thread, apologies about not doing
> it right the first time...
>
> --
>     Viktor.
>
> >              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
> time.
>
> I agree but as far as can see the cap of the TTL with a revalidation will
not only resync the resolver and the zone more often than could be expected
otherwise but does not result in the cached RRsets differing from those
provided by the zone.


> 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
> RRset.
>
> 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.
>
> I see your point. Our goal was that a RRset could not sit in the cache for
ages because a TTL has been wrongly configured. Using the 'cap' method,
such a re-synchronisation is forced which generates unnecessary additional
requests.  The 'revalidation' method resynchronization happens only when
the signature will not match, that is when the key has been changed - which
is the only way the validation can fail. I do not see keys being
rolled-over sufficiently often to address our initial concern on a regular
basis that is every TTL_(ZSK, DS). That said, it provides the opportunity
to the zone admin to eventually force that refresh in case of a mistakenly
long TTL value.

I do see the revalidation mechanism as providing assurance that the cached
data remains coherent and this is probably what we should do - I agree with
you it seems a better compromise. Now one reason I think we also came to
the cap, was that though we know tweaking the TTL is possible, I had in
mind that adding a field like in our case the 'revalidation TTL' was much
harder. Can we assume such a mechanism can realistically be implemented ?


> 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.
>
> I agree.


> > 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 ???"
>
> I think the current phrasing might be better:
This document clarifies the scope, the responsibilities of a DRO and the
operational  that DRO SHOULD....

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.
>
> ok I see your point.

> >    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.
>
>     s/certainty/assurance/
>
> thanks.

> >                         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.
>
> thanks.

> >    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.
>
> yes, actually we have been working on updating and reducing this section.


> >    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
> diversion.
>
> yes the current revised text is addressing the concern.


> >    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.
>
> I agree.

> > 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.
>
> This is interesting as we received a similar comment from the secdir
review. Our message here was to mention that when a signature fails the DRO
is actually doing work and should not be found guilty if someone badly
signed its zone. If you have a better wording that would be appreciated.


> >    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.
>
> I will see how we can do it.

> The document IMHO needs some overall editorial attention.
>
> yes, we are working on it.

> >    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.
>
> > 11.  Cryptography Deprecation Recommendations
>
> >    STARTUP: * DRO MUST ensure recent software releases that comply with
> >    the most recent cryptographic guidances are being used
>
> >    RUNTIME:
>
> >    *  A DRO SHOULD regularly request and monitor the signature scheme
> >       supported by an authoritative server.
>
> What does this mean?
>
>  I think the intention was to pay attention to the algorithms associated
with the keys, ds, and signature.

> >    *  A DRO SHOULD report a "Unsupported DNSKEY Algorithm" as defined in
> >       [RFC8914] when a deprecated algorithm is used for validation.
>
> How?  To whom?
>
> I see that is the other part of the resolver. we meant here to the stub
client.

>    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.
>
> The intention was that DRO can advertise their support of recent
algorithms, so they can give authoritative servers more confidence in
deploying them.

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Daniel Migault
Ericsson