Re: [dnsext] Clarifying the mandatory algorithm rules

Matthijs Mekking <> Wed, 30 March 2011 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4953E28C0DE for <>; Wed, 30 Mar 2011 13:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DJgZ5J0J4YPu for <>; Wed, 30 Mar 2011 13:02:43 -0700 (PDT)
Received: from ( [IPv6:2001:7b8:206:1::1]) by (Postfix) with ESMTP id 223913A6BBE for <>; Wed, 30 Mar 2011 13:02:41 -0700 (PDT)
Received: from [IPv6:2001:df8:0:64:215:afff:fed2:e121] ([IPv6:2001:df8:0:64:215:afff:fed2:e121]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id p2UK4JRx088067; Wed, 30 Mar 2011 22:04:19 +0200 (CEST) (envelope-from
Message-ID: <>
Date: Wed, 30 Mar 2011 22:04:19 +0200
From: Matthijs Mekking <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Edward Lewis <>
References: <> <> <a06240801c9101620d463@> <> <> <> <> <> <> <> <a06240800c9a50cf4632a@> <> <a06240802c9a7b6cb4cc3@> <> <a06240802c9a7e0807069@> <> <a06240802c9a93d762e13@[]> <a06240803c9a9417e1fe8@[]>
In-Reply-To: <a06240803c9a9417e1fe8@[]>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 ( [IPv6:2001:7b8:206:1::53]); Wed, 30 Mar 2011 22:04:20 +0200 (CEST)
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 20:02:44 -0000

Hash: SHA1

Ok, so let's try to come to a reasonable clarifying text:

- -------------------------------------------------------------------------
Section ?.? Clarifying the validators interpretation regarding multiple

RFC 4035, section 2.2 talks about Zone Signing. It mentions that

 "There MUST be an RRSIG for each RRset using at least one DNSKEY of
  each algorithm in the zone apex DNSKEY RRset".

This is a requirement at the server side, not the client side. In other
words, when a validating resolvers is in the process of validating a
RRset, it SHOULD NOT expect a RRSIG of each algorithm that is in the
zone apex DNSKEY RRset.
- -------------------------------------------------------------------------

This only fixes the misinterpretation on the expectation a validator may
have. It does not deal with algorithm downgrade protection at all (as
some may believe does not exist in DNSSEC). If there is need for
clarifying algorithm downgrade protection, or its non-existence, I
suggest something in the line of:

- -------------------------------------------------------------------------
Section ?.? Algorithm downgrade protection.

The validator could check that there are RRSIG records for each RRset
using at least one DNSKEY of each algorithm in the DS RRset, published
in the parent zone. This ***

*** Choice here
- - is however NOT RECOMMENDED. ['the one signature is enough approach']
- - is OPTIONAL. ['leave the choice to the implementation' approach]
- - is RECOMMENDED behavior. ['algorithm downgrade protection' apprpach]
- -------------------------------------------------------------------------

Best regards,


On 03/18/2011 06:07 PM, Edward Lewis wrote:
> I should add...just because "there's supposed to be X" doesn't mean X
> has to be there.  If I'm looking for X and it's not there, we have a
> failure.  If I'm not looking for X and it is not there, "no harm, no
> foul."  (The latter is the same as not needing X and it's there anyway.)
> At 12:59 -0400 3/18/11, Edward Lewis wrote:
>> At 9:36 -0700 3/18/11, Casey Deccio wrote:
>>> Okay, so the signer sets the expectation of the validator using the
>>> algorithms in the DS RRset.  Now, does this expectation hold for
>>> simply authenticating the DNSKEY RRset or for all zone data?
>> No, the specification sets expectations.  I don't mean to be a pain,
>> but the first words say this: "The reason for the specification is to
>> set the expectation."  I mean that in the strictest sense.  The
>> validator knows there's supposed to be X because the spec says so.
>>> For example:
>>> - DS RRset has only algorithm 5
>>> - DNSKEY RRset signed by a DNSKEY matching the DS (alg 5)
>>> - DNSKEY RRset contains DNSKEYs with algs 5 and 3
>>> - DNSKEY with alg 3 signs A RRset.
>>> Is there a valid chain to the A RRset, or is it a protocol failure?
>> Depends.  If the validator knows both 3 and 5, then it can build a
>> chain and it's cool.  If the validator only knows 5, then there's a
>> missing piece.  If the validator only knows 3, there's no chain to the
>> data.
>> In summary:
>> Validator knows 3 & 5 - validates
>> Validator knows only 3 - data is accepted as not-signed.
>> Validator knows only 5 - service failure as *expected* signature is
>> not found*
>> Validator doesn't to 3 & 5 - accepted as not-signed
>> Validator doesn't do DNSSEC - accepted as not-signed
>> *not found = not obtainable, can't get it, ...
>>> Following the principle of "if one chain works, it succeeds", I would
>>> say
>>> that it is valid.  But it's unclear whether this is part of the
>>> expectation
>>> of the signer for the validator, and even the paragraph quoted above
>>> seems
>>> to declare it a protocol failure--although I well understand your
>>> position
>>> on principle.  Whether it is valid or not, I believe it should be
>>> worded explicitly to avoid ambiguity and accurately convey principle.
>> It is always up to the validator to decide if it accepts the data.
>> Local policy and DNSSEC is about protecting the cache.  DNSSEC is NOT
>> designed to enforce proper operations, it is NOT to force the zone
>> admin into doing anything.  Remember, DNSSEC is optional to the
>> protocol, it's the validators that want to pull the data for protection.
>> -- 
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> Edward Lewis
>> NeuStar                    You can leave a voice message at
>> +1-571-434-5468
>> Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
>> Son: "Waah!"
>> _______________________________________________
>> dnsext mailing list
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -