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

Shumon Huque <> Wed, 19 July 2017 12:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E9FE131B13 for <>; Wed, 19 Jul 2017 05:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 ZQouNPqaHwqF for <>; Wed, 19 Jul 2017 05:28:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4E2A131451 for <>; Wed, 19 Jul 2017 05:28:38 -0700 (PDT)
Received: by with SMTP id o19so1221166vkd.5 for <>; Wed, 19 Jul 2017 05:28:38 -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=ZJy/Hc2yVNoMFymP9qgdfig8yn+LVYgSqHsV0laKKaY=; b=SRjfnqYwnftq49s4j80Q/R5xikQfIRw/UrtTk67pNojkia6OmkK0hulDRtGeK+3R0/ yqjjqFp/2dQEh3BAyP5TWjaozCqwtEWSikzgEiTLk9aG9bX9I1fWbKZzmfSnzTFjM5b/ 86aqxtYzQzd1fXyDT/JSi2Rv/xMfpHYqzOXEbcGqJ5DB3iLbliDmrPtUzupCZvOb1jvF 105IMkcuQQgeOZW+cZmFKLyONC4wIpo1vWAftK0d0ZER4JXWNFNeedKXq8PTDAjG3CfZ A816P8qO/F/W0Z9EVNr0jghBQ3gaGMxeQvxqSEI2rC04YTHzcCF6GYfXwbu/B2cuA6h1 lKVQ==
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=ZJy/Hc2yVNoMFymP9qgdfig8yn+LVYgSqHsV0laKKaY=; b=qF3AdpaG9fscUVHISKrzvNkkEc+2wCeBfcc8XwE/2cOxU9Iu2iQAeWlqDAzZCK10ES M06iDWXPQGjJRr1Pw1+FqqaRVtvXiOBwoCMtH5/bQ32JimjimTXUXRLbspMlPmWF8IWt RTf9e7vabiSzqB+HG8hayoy5mq/2ciNXpTkggxwhG7ThXTMVQ/vLH3LWWaEKBz7CLGNG eXUEMejfShq6/JArgm6VOs0PchYc+SJywQhB+dVMtmJkZO90t1fjkYBVSaxZB7XDprfa 2hUKLFGuPAzqYo+L4nKXclJhz23OtiRYPYFIPIy5K2XNqf/2Y5+4RA+yZETFm4+AJzJR XnBQ==
X-Gm-Message-State: AIVw110YZEJs4Ws6pQH07fRmN3U5ohWB6B/mg3xI1URey6S+Kouct5cD AQT+IuGN3F/vwqTZ7ZtCH7OL+h3cdQ==
X-Received: by with SMTP id b135mr1358232vkd.22.1500467317892; Wed, 19 Jul 2017 05:28:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 05:28:37 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Shumon Huque <>
Date: Wed, 19 Jul 2017 14:28:37 +0200
Message-ID: <>
To: Stephane Bortzmeyer <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="001a1149267a7aeced0554aac50d"
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: Wed, 19 Jul 2017 12:28:41 -0000

On Wed, Jul 19, 2017 at 10:49 AM, Stephane Bortzmeyer <>

> On Tue, Jul 04, 2017 at 11:42:56AM -0400,
>  Shumon Huque <> wrote
>  a message of 108 lines which said:
> > We've posted a new draft on algorithm negotiation which we're hoping to
> > discuss at IETF99
> For the discussion on thursday:
> > In contrast, many other security protocols, like TLS, IKE, SSH and
> > others, support an algorithm or cipher suite negotiation mechanism
> TLS and SSH are end-to-end. Not the DNS, and it makes things more
> complicated (see section 6).

Yes, that's certainly true!

> > because fragments are often blocked by network security devices.
> by STUPID AND BROKEN network security devices. Otherwise, you do not
> put the blame where it belongs.

I was being polite :-)

I don't disagree at all. But as practical matter, it is still an
operational problem that needs to be dealt with. I would love to eradicate
this problem Internet wide (which I think is Mark Andrew's preferred
solution), but I doubt it will happen any time soon.

> As can be readily seen from the RSA to ECDSA transition, very few
> > zones have transitioned from RSA to ECDSA,
> True, but not for the reasons of the response size. Both for my
> employer's zones and for my own personal zones, the big issue is the
> lack of support in tools like HSMs, the difficulty of algorithm
> rollover, and the fact that tools like OpenDNSSEC don't make it
> easy. So, we have apparently a disagreement on the basic diagnostic.

It is a problem for some sites. I agree that there are other problems that
dissuade people from algorithm rollovers. But this just means that we need
to collectively work on making this easier, whatever the reasons. This
proposal can address some aspects of this.

> the resolver has selectively cached signatures of a subset of
> > algorithms supported by the zon
> How does it know? I mean, in the response from the authoritative
> server, nothing indicates if the signatures are a subset or
> not. 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.

> > but prefers algorithms known to be supported for the name,
> Again, where does this knowledge come from?

When the resolver queries the DNSKEY RRset for the zone, it knows which
algorithms are supported for the zone.

We're working on some additional tweaks to the protocol, which I'll discuss
on Thursday.