Re: [DNSOP] [Ext] comments on draft-mglt-dnsop-dnssec-validator-requirements-05

Daniel Migault <> Thu, 20 July 2017 11:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96F3F129AD1 for <>; Thu, 20 Jul 2017 04:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VGmhK8uV3TqF for <>; Thu, 20 Jul 2017 04:11:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34DE512EAF0 for <>; Thu, 20 Jul 2017 04:11:07 -0700 (PDT)
Received: by with SMTP id m86so3621502lfi.4 for <>; Thu, 20 Jul 2017 04:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Fwnenff2EgOCLxYOAl5NNo2WeKSd1c+uDom3cQlfPdw=; b=sheVY/wmWeKwWR9TfjOt4kUhGHHq6FI32bV1yHZ/wedufeSoZuZ7mjJvmWbSWTG375 x0HaLFVdVJW0+FyxmbGovD1D5pKUYQG3V2RvAvxUFDbsgbeA9VWhWtV//EHpkTiLserB b3C4zXHyGKC23gO6k4O9JSC1bEPuVkdFaCQo82ibKTaZcsrZwwxQikjB5zgUsVkbHb5O VP+xiN/Pq412JNiegPhgmhRlaFCVlB9d/Tm77J/tRy4T86Hw0I8J5X6aaPpU1uFnLvwZ 64B7Y0ausSLJcTIUjRDr1NU5eTkjGzi/Hh+FAHf7NZLncEVKf0L0tqhQZ3LT0BCQdP0U mtJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Fwnenff2EgOCLxYOAl5NNo2WeKSd1c+uDom3cQlfPdw=; b=pMRPaFqH0I9Uc5XaCQcizprSgIaFPT/ruPgjsRF/C9gULDKaUJhwAd+jOBamB376FN F8h4GIDcbQ7Oyp1zGDEuA+bOifXGOTICwku2KEeONi3FQ8p6MVZZnVPoxvGKDnE2P8dY yhHYb9kHyzrzPcnC3gRyO9HrH4ThqLEm1Xf4aIgghms+2giUaZ204ig01hTS2ZrhVTxe WfdBVjUk/2lU9KJSImI8jm+PcATraKkyHN35IrBI52utsPGno9JOiK1r3zI9OowZwjfS JXZA6/fBTBChGxoIacamXpyT8gRBFTFZnz6xO6zQcdLw1qaFUbyUlNeRZBySIHerUGF8 RUjQ==
X-Gm-Message-State: AIVw113XTJTYYPoFPkhYsXLkIoQDVjS03dqiStHi54pfAtixzTwZ4+Os W4P4x8mMtUAUy2bBfLvneviB96xEsw==
X-Received: by with SMTP id f27mr1324786lfa.167.1500549065513; Thu, 20 Jul 2017 04:11:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jul 2017 04:11:04 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Daniel Migault <>
Date: Thu, 20 Jul 2017 13:11:04 +0200
X-Google-Sender-Auth: DX9hxI6FWQawyhSRq-wT2mhKgGQ
Message-ID: <>
To: Edward Lewis <>
Cc: "Rose, Scott (Fed)" <>, "" <>
Content-Type: multipart/alternative; boundary="f403045ea33e04a1250554bdcedd"
Archived-At: <>
Subject: Re: [DNSOP] [Ext] comments on draft-mglt-dnsop-dnssec-validator-requirements-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Jul 2017 11:11:10 -0000


Thank you for the feed backs Scott. We will address them in the next

The motivation for crypto deprecation is clearly to follow the crypto
recommendations stated by the IETF. However, this requirement for the
validator is to actually "validate" those requirements are effective. The
intent is clearly not to overcome the crypto recommendations.  But you made
a good point, and we will address this.


On Wed, Jul 19, 2017 at 5:01 PM, Edward Lewis <>

> On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" <
> on behalf of> wrote:
> >I think this draft is a good idea and should be adopted, but needs some
> improvements first.
> >
> Thanks for the review, the current version has items needing wider
> discussion.
> I'll pick some items to respond to now:
> >2. REQ2: What should happen when there are multiple trust anchors, but
> only one failed to validate? E.g. a validator has both the root and
> .exampleTLD in its trust store, but missed the root rollover. The
> .exampleTLD key still validates, but the root doesn't. Should all
> validation stop? Or set a warning, but continue to validating (succeeding
> only for .exampleTLD)?
> One of my long-standing opinions has been that it is hard to build a
> secure chain, so if one exists, accept it in face of alternative broken
> chains.  If a validator is too "tight" then it would be trivial to do a
> denial-of-service by throwing out DNSKEYs, RRSIGs, etc., that will not lead
> to validation.
> As far as trust anchors, the level of trust (healthiness in some sense) is
> individual.  One anchor candidate might be "false" (unauthorized) while
> another anchor candidate might be "true" (authorized).  Trust is in the
> eye-of-the-operator, if the operator establishes trust in a candidate it is
> best to run with it, again, even if there are untrusted candidates.
> (Because, if too "tight" it would be trivial to do a denial of service.)
> >3. REQ18: I don't think I understand this. Wouldn't the best way to see
> which algorithm(s) are in use for a given zone would be just to send a
> query  Authoritative zones really may not "know" any algorithm besides
> SHA-1, as it is likely not doing online signing, but serving whatever a
> signing utility chose.
> I'd refrain from "know" and use "use."  The signer (not the zone) may or
> may not have a library for a particular DNSSEC security algorithm's needed
> cryptographic algorithm and/or hash.  That's entirely opaque to the other
> side of the DNS protocol (as DNSSEC assumed an air gap in the most strictly
> secure use case).
> What is in use for a zone is established two ways.  One is from the DS
> RRset.  The other is via published secure entry points bootstrapped to the
> satisfaction of the validator operator's "trust" satisfaction.
> I.e., I too think that REQ18 needs further review.  It would make more
> sense if there were on-the-fly signing capabilities (which is not something
> assumed by DNSSEC, although it's not a ludicrous idea, it would be
> operationally useful).
> >4. Should there be a mention as to which algorithms a validator should
> support? It may not require a direct reference to whichever RFC is current,
> but simply listing the IANA maintained registry and say "implement all the
> MUSTs and probably the SHOULDs too". Something like the following:
> For turn-key implementations, I don't think so.  For general-purpose
> implementations, the producer of the software would make a choice based on
> their objectives.
> Easing the choice for the tool developer would be good, but I question
> mandating compliance with features.  (I'd leave that to the "purchasing
> vehicle", which begs a whole'nuther discussion.  There would be a need to
> educate the consumer, for one.)
> >Algorithm Usage in Validators
> >
> >DNSSEC signatures can be generated by different digital signatures
> algorithms. The current list of algorithms defined for use with DNSSEC is
> published in an IANA maintained registry [insert IANA link here].
> Validators have to be able to understand and validate different algorithms
> that may be in common use with DNSSEC. The DNSSEC digital signature
> registry table is regularly updated with guidance as to which algorithms
> are considered MANDATORY and/or RECOMMENDED. In order to be effective, a
> validator MUST understand all digital signature algorithms marked as
> MANDATORY and SHOULD understand all digital signature algorithms marked as
> >
> >REQXX: Validators MUST implement all MANDATORY digital signature
> algorithms and SHOULD implement all RECOMMENDED digital signature
> algorithms.
> >
> >Note: This wording isn't the best, and needs some work. I also don't know
> if the SHOULD in the REQ should be changed to a MAY, but I would prefer
> Thanks for the suggested text, for the most part I think it is on target.
> But to hark back to my comment before it, I'd change (for example):
> "Validators have to be able to understand and validate different
> algorithms that may be in common use with DNSSEC."
> to:
> "General purpose validators, in order to be widely adopted and accepted,
> ought to implement as many of the commonly used DNSSEC security algorithms,
> with "commonly" interpreted, at least on one way, to include the DNSSEC
> security algorithms in the IANA registry noted."
> ...again, wording is loose.
> My driving concern is that there may be some folks that have a turn-key
> situation in mind; the IETF famously says it is not the "protocol police."
> _______________________________________________
> DNSOP mailing list