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

Shumon Huque <> Mon, 10 July 2017 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12BEC131865 for <>; Mon, 10 Jul 2017 11:53:47 -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 4kGTb9VmwopD for <>; Mon, 10 Jul 2017 11:53:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D30AB12EC3A for <>; Mon, 10 Jul 2017 11:53:44 -0700 (PDT)
Received: by with SMTP id y70so52368531vky.3 for <>; Mon, 10 Jul 2017 11:53:44 -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=YzQ6UtnL5a+yn8iePtUhY5hjiZ/JEpvDrrj6vZ63JtU=; b=D6coRsin154SUgggyvcaKcbTq8aovGv3apLRcjY37+3Y11fyjc57sxcJuu5kZBjSnP qX/x2J34xzTNU1yDwj+Jx918eJYUyF+pk7YBzVnobxbBnnEnAyYwVpowMfzRvmOTegj2 3ICjEq5VdBBOtCw8KctXsXUhMr8IULtl1fx4y2y1dK9aVmKwo4D4YKS3TMdzMjzWFzA5 jdPFOr13B4tgvtnN6aErsFje2gzNgHikuQU2Xji240dG/fo031b7WpYsZL0bn25mbKJY XtaGxGo7ubZ6NLt6QFE5jM0izGDlhVipk6W/7sw1UYtMhugQ/xKrJn1kbS9tyfkfOxhX jafw==
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=YzQ6UtnL5a+yn8iePtUhY5hjiZ/JEpvDrrj6vZ63JtU=; b=Fp8kWghyKXV+0gsDmgDhcZfPzFMZ8vvaSP/xxpvUrhhOm5HanftD0zIxOHdjCledgd vC2y4VhNaANUZcUe8C05rexdojRxKrMzQ0eWsp3eEQtkAgqSUCx5BAWTNdCRrwlC9jSU qcPcxxFNgixNYR8lyD+/Kw081b5PTLjWGeGiI49eiBg6gI9RsqIxZx82TVm8QHRteMoB ngF2QQSz55fYbRJKwtDmi4OLbjq5iJXWAfiZHrvxFAucufTsw2ydBpvkSQR8gJ3PjvQl lRX2vUE3rhcHX1RHZObkXkpkkBM0Z1mcxgZm7TxJiMb3wz7ydm1Pt5ld/mEdOoOVnsBQ isRA==
X-Gm-Message-State: AIVw112yMuDdnmX2R0l2yjGuN6tXjBsHKRU1vEu32pmJh4K5gRUVsJpR QTqZvWEbgDRRYSNVX73JWw65qdtVkw==
X-Received: by with SMTP id 70mr6765812vko.99.1499712824013; Mon, 10 Jul 2017 11:53:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Jul 2017 11:53:43 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Shumon Huque <>
Date: Mon, 10 Jul 2017 14:53:43 -0400
Message-ID: <>
To: Bob Harold <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="001a114551aa23f88b0553fb1a43"
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 18:53:47 -0000

On Mon, Jul 10, 2017 at 1:50 PM, Bob Harold <> wrote:

> 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.
>> --
>> Shumon Huque
> I like the idea.  I am not an DNSSEC expert, but wondering in section 7,
> paragraph:
>    In order to detect such attacks, the client SHOULD compare the zone
>    signing algorithms listed in the zone's authenticated DNSKEY RRset,
>    and the preferred list in the query that it sent, to the algorithms
>    seen in the response signatures.  If signatures by the most preferred
>    algorithm they have in common have not been sent, this may indicate
>    an algorithm downgrade attack.
> Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to
> would not be available for response signatures?

Hi Bob,

Very good question Yes, there certainly can be. If the pre-published key's
algorithm is higher strength than the others, then it could cause the
resolver to mistakenly deduce an algorithm downgrade attack might be in
progress. I think this argues that we really do need the new zone apex
(active) algorithms list record - which we already were thinking of
proposing - in the last paragraph of Section 7.

And perhaps a really dumb off-topic question:
> I do not use DNSSEC yet, mostly due to time and effort, secondly due to
> concern over the additional size and processing.  Is it possible for me to
> start with a new, rarely implemented, algorithm with shorter records, that
> most resolvers won't understand yet, and have those that don't understand
> it treat the zone as unsigned?  Or will it break everything?  (Section 5
> sounds like it breaks)

(Only) Unknown algorithms will currently cause resolvers to treat the zone
as unsigned (fail open). So, nothing will break, but resolvers that don't
understand the new algorithm won't authenticate the signatures and the
benefit of DNSSEC is lost.

Shumon Huque