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

Shumon Huque <> Mon, 10 July 2017 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DB3E13192D for <>; Mon, 10 Jul 2017 15:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_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 Br0U4sBivsAT for <>; Mon, 10 Jul 2017 15:16:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C11D13190C for <>; Mon, 10 Jul 2017 15:16:55 -0700 (PDT)
Received: by with SMTP id y70so55127886vky.3 for <>; Mon, 10 Jul 2017 15:16:55 -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=ARm66Pyr5HNRMFFeMChG4vQpvstTgo9+41FqtJIhQrM=; b=dEKJ0vKUOKZfsXG6yS4hk57cu0wS/LWqF9YXzIVe7Jheo35pfGOz1ynW1QMzY52IIe 9c/iNaXlPdQW36hCccvWg1bakph6wUzfpRHIeO12lwNb1rJS6s67vSVo/w3pGWe7Kq7u zAoeN4vJGmx5fCN1M5b/HpiAuLlTLPcxgAfVPLY20Jn3gFUyR+9U7HMUhqKptjoK/Qge u/GI/dCmQhmQwJwI0Hqr0zbr8oY85EfPI982WtleIGvi/BoBf7DJC3NbZmGO0APucj28 vgcJNO5w/GO00JX1o1ilGx22bl9nHa1F1or+fD7wF+jMTKznGS7SK1sobaptBD3l86uj Ywww==
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=ARm66Pyr5HNRMFFeMChG4vQpvstTgo9+41FqtJIhQrM=; b=tU2hsoIWI1sAKn6/mISUo8RJoPmA3zW/mDvjV4JQXjaD7Ke/pYmlhDjN8i8G6sCFx5 3XWqdI6K5TxlBSiq7oMoY3k6OxMFh+vdceybv+llSw4LzXeFfGXIh8lpddvHCA1jelxj +pqxdXEPSgNtgwRgMizJzauBshziOKF70QRMMX58GN6oRUTGL9JctkplzFVjGbK091X+ QR9e1LpsVlfy/ML91m/SS4Cy9hj9c1ghLBiXgr05TNKQW2HzR2h6tsQ4HlSRGNVyDJta YuEHwougWQbhAInjMWCzgBFO1h3WI48Xy0TIcDKe9FIIE2B+FEeeThDgAsXnHRoHYa4e XwGw==
X-Gm-Message-State: AIVw113Au6xs/bs0n47ThKhQDmi3K1Em+fyrmAk6Dm8bl27VCV504Tsx Srv/zzFASUFuO0FSldgxNugz/V+i8Q==
X-Received: by with SMTP id e139mr5906585vkf.69.1499725014249; Mon, 10 Jul 2017 15:16:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Jul 2017 15:16:53 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Shumon Huque <>
Date: Mon, 10 Jul 2017 18:16:53 -0400
Message-ID: <>
To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="001a11439b7abc379c0553fdf056"
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 22:16:57 -0000

On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson <>

> Shumon,
> 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.

As I tried to explain in my previous note to Paul Wouters - fail open is
horrible for DANE. Protocols can evolve. If DNSSEC had algorithm
negotiation from the beginning, fail open would not have been necessary.
This fail open behavior frequently takes people not in the DNSSEC club by
complete surprise. I've lost track of how many "WTF" moments I've had to
explain to other people about this behavior. This proposed behavior change
is also signaled, not unilateral. But let's debate ...

Section 6
> This is hopeless algorithm, that goes against the justification of the
> document.
> 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.

There has to be some initial fallback behavior with costs. This is not
uncommon in new protocols. Think about longer term benefits.

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

See previous discussion.

> 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

DNSSEC already has a DDoS reputation - this isn't going to make things that
much worse. Also DNSSEC has already been way surpassed in this area by
NTP/SNMP etc. What we should be working on is deployment of proper protocol
level mitigations, like Cookies, etc.

Shumon Huque