Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

Shumon Huque <> Thu, 20 July 2017 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10CE7129AA0 for <>; Thu, 20 Jul 2017 01:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OQMJK5mY9iK9 for <>; Thu, 20 Jul 2017 01:08:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1FC8126557 for <>; Thu, 20 Jul 2017 01:08:28 -0700 (PDT)
Received: by with SMTP id 80so17396077uas.0 for <>; Thu, 20 Jul 2017 01:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W7reEN2gjS9hErcUfGNQMDb4R+8lUqTuBtg7kKfmGTU=; b=g5t2leybvMY4TOqCwqbRPDC4TMA2wuE1n025LD00XR+xL5fkWU7F/FgbfzIDRdgps1 m07kskYfM+0CkRbESdSREVCrJgnNYnnLCnKxt+/XxWj5S/PXHDi4dDj223z64d3OxTLe I2E1DdqcCTqXJGNxwPxdM48x0eeIp05vJsc6ObXA3VaK+kB8scPgUr/1NZ/acF7z/g3N kOk9GWY+gvCXaYa57Lng7F0ZBYeLcm2zqiPf9aO+BmIglGKCWmfzMTZbVyGbSvTEphsl 9gwf0IGRQoK7KpCE9hrMx8mRvfnsGysYu1T1tTwNCgZD+o3TMGvY51LfbFc4zbcom2vB qaAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W7reEN2gjS9hErcUfGNQMDb4R+8lUqTuBtg7kKfmGTU=; b=ANP0VOwCSPeEG+bpDMP+PE0LNzFzCv+0/cT/oCxmCgeijACVZHCPRUiAQx7jRlM0Qb LmkKMpKmCjLmihfRzDA26RIeahDoa74BHioNajEc+MEloZaH/+jjlT3aVW7euafeOKvu LSElmgQQ6dGDBOTckNmzuDKjdW573vTsfnJYJL1eE0rSLCZhA2jZUOqq4lW0mN1BoLJm aeUKNtRb61OeLrNYQCtXk/GzuK3JsXTwrLsqgrkG6xKTehTTCFpDq/q6os4J8mY0vgxW fyas22WLYX1tNB7yEjipNH4m+sDfVPde7fqskUmg3cn3D4IWXSS5ZuOb0q+EXsZUhgbO WsCg==
X-Gm-Message-State: AIVw110a5ptUbrdRyDKr96dREW/DVcp1tb/ZUsrszQyevG7yaU/F8mD4 52g1ZNuXTnM/mBu3fPjYvDRhjm4SuA2gFNc=
X-Received: by with SMTP id j9mr1531746vkc.171.1500538108157; Thu, 20 Jul 2017 01:08:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jul 2017 01:08:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Shumon Huque <>
Date: Thu, 20 Jul 2017 10:08:27 +0200
Message-ID: <>
To: Stephane Bortzmeyer <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="94eb2c14a21ee8a3c00554bb40cb"
Archived-At: <>
Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC
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 08:08:31 -0000

On Thu, Jul 20, 2017 at 9:51 AM, Stephane Bortzmeyer <>

> On Wed, Jul 19, 2017 at 02:28:37PM +0200,
>  Shumon Huque <> wrote
>  a message of 153 lines which said:
> > > Suppose I send the list ECDSA;RSA, and I receive only ECDSA
> > > signatures. How the resolver/cache would now if it was a complete
> > > list?
> >
> > The response contains the EDNS0 option if the responder executed
> > this protocol. In which case, the cache would tag this response as a
> > subset.
> Sorry, I still do not understand. The EDNS0 option does not indicate
> if the set is a subset or not. Or do you assume that, if the response
> indicates that the responder executes this protocol, an answer is
> always a subset (even if it's not)?

The EDNS0 option, if received from the server, indicates that both (1) the
server understands this protocol and (2) the server executed this protocol,
i.e. that response includes a subset (specifically 1) of the deployed
signature algorithms. I think the latest draft says this, but if not, I'll

Also, if the server uses only one algorithm, but understands this protocol,
then it probably shouldn't include this option, because there is nothing to

> > When the resolver queries the DNSKEY RRset for the zone, it knows
> > which algorithms are supported for the zone.
> You can have keys which are not used for signing (such as in the root
> today).

Certainly, but only for the same algorithm. If there are multiple
algorithms in use at an authoritative server, then there needs to be
signatures associated with each algorithm.

RFC 4035, Section 2.2

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

Shumon Huque