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

Ólafur Guðmundsson <> Mon, 10 July 2017 21:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBDC01318EA for <>; Mon, 10 Jul 2017 14:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dKq4V7rIxFgY for <>; Mon, 10 Jul 2017 14:01:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC0F61318D7 for <>; Mon, 10 Jul 2017 14:01:17 -0700 (PDT)
Received: by with SMTP id d78so84653640qkb.1 for <>; Mon, 10 Jul 2017 14:01:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oIEqbFP6i8JFQC3X/RT/N69vTIS5kLDuTvW2f0zocFg=; b=rgJB90LDr/rBfaP461oGnJkRTB5Zu669m80m+p8dWvbjiIosb64LY104YvDpwaYs0i rAeWH8lA6nUY6wYS9PHtZ4+t0sP549vlF8/2VjlPMfhOWV0eOPn5oCtxy+GN2NuuLYgj BUwUEVzkksksNqXuHTSSy1xj6BryEaoHcJVLk=
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=oIEqbFP6i8JFQC3X/RT/N69vTIS5kLDuTvW2f0zocFg=; b=P7NZSBNMpH5Q8LJ9wlDey0ZUKnEVjJS+g4o0HB0XdjVTTikrpo3DAXv/UWj46Qm4X+ QPvRwVvZUpjSHBX1FkfGdD6GEKQUcr0dg1vVFn1rBva2hgV8GZ4DVVgMCstjdnXRzQZM eAFb6FY2/5b4x9+Qle6KBX/cNaDStogAKE8U2muu2kEBkqPVltjIPuoS1MSAULDFrM9m ec64DJhyiU5IDtD3i8wcZsXSSvCMeA7PM5FqeTD2H5SrJ9sKLFrnwA2HiyQdFwUq5Rk7 ZxoPMfFZaVNqrJpnO54GErH94nOR6XbnOs/W8UHE09BacvCuF+nuDeAwIqlsqY68NTXw NVNw==
X-Gm-Message-State: AIVw112Pq0gqoffO5Jhg58SM49MEbg+W7RdvXQqUd7/XEMWoRZ9zrkIj EbF6G9ciBZ3BEs1h1RqE71ICpQ1qayMa++3V0g==
X-Received: by with SMTP id c193mr6075934qka.232.1499720476851; Mon, 10 Jul 2017 14:01:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Jul 2017 14:01:16 -0700 (PDT)
In-Reply-To: <>
References: <>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <>
Date: Mon, 10 Jul 2017 17:01:16 -0400
Message-ID: <>
To: Shumon Huque <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="001a1146f28e4926a00553fce23f"
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: Mon, 10 Jul 2017 21:01:20 -0000


In section 5 your draft says:

   If an Authoritative Server has no algorithms in common with the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.

This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

Section 6
This is hopeless algorithm, that goes against the justification of the
basically it may force validating resolvers to fetch the answers multiple
times for each TTL; once without DNSSEC, then for first algorithm, then for
all algorithms ==> right now validating resolvers only fetch once with
DNSSEC enabled.

This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

overall this draft main idea: DNS publishers should sign with more
algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set
==> better for DDoS


On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <> wrote:

> Hi folks,
> We've posted a new draft on algorithm negotiation which we're hoping to
> discuss at IETF99 (and on list of course). I've discussed this topic with
> several folks at DNS-OARC recently.
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>         Title           : Algorithm Negotiation in DNSSEC
>         Authors         : Shumon Huque
>                           Haya Shulman
>  Filename        : draft-huque-dnssec-alg-nego-00.txt
>  Pages           : 9
>  Date            : 2017-07-03
> Abstract:
>    This document specifies a DNS extension that allows a DNS client to
>    specify a list of DNSSEC algorithms, in preference order, that the
>    client desires to use.  A DNS server upon receipt of this extension
>    can choose to selectively respond with DNSSEC signatures using the
>    most preferred algorithm they support.  This mechanism may make it
>    easier for DNS zone operators to support signing zone data
>    simultaneously with multiple DNSSEC algorithms, without significantly
>    increasing the size of DNS responses.  It will also allow an easier
>    way to transition to new algorithms while still retaining support for
>    older DNS validators that do not yet support the new algorithms.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> --
> Shumon Huque
> _______________________________________________
> DNSOP mailing list