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

Paul Wouters <paul@nohats.ca> Mon, 10 July 2017 21:00 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616612F299 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 14:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfngDpX6w7hy for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 14:00:46 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC621318EC for <dnsop@ietf.org>; Mon, 10 Jul 2017 14:00:41 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3x5yKf601dz37h; Mon, 10 Jul 2017 23:00:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1499720438; bh=65BkOoHZ8rJ+C6tMx5xeH/BpHWjwMKKYQr/FGaXK55A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CCqA8xbkaftph+Nkl2rRp0eJVit/IMPxcYqQHr3vaeD2ARlDKqOp5HUzoobjGjqYv RXJOYD8WbSagwxpfYTNHcymRK7pNKvknn/KjSz8HWsxgwtoq+npX1D2hgAMfWjGA0J GjekabARHmQ00YIlkR49InAEe2v4MbxB5zanIgAk=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Po2MwX1l1hQ3; Mon, 10 Jul 2017 23:00:35 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 10 Jul 2017 23:00:35 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0285730AF11; Mon, 10 Jul 2017 17:00:33 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0285730AF11
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8DDC40D3592; Mon, 10 Jul 2017 17:00:33 -0400 (EDT)
Date: Mon, 10 Jul 2017 17:00:33 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Shumon Huque <shuque@gmail.com>
cc: Bob Harold <rharolde@umich.edu>, "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <CAHPuVdUnUhfVtvgBWbyXD1fWjz04QMKp59Ar1HNonmAkJeLj6A@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1707101641220.31889@bofh.nohats.ca>
References: <CAHPuVdUVQqvFZJFV4D88cg4fGfFqxnzAwj1VRr6oK7Y1n9hDUw@mail.gmail.com> <CA+nkc8BiSMSNqa9FifNAqWiZuf7prVjD6EKSnbFjq_EWi8kSoA@mail.gmail.com> <CAHPuVdVWi-4nQeoBuyKe7f81mieVpznFwd25Nb5at6t-JpYzUA@mail.gmail.com> <CAHPuVdUnUhfVtvgBWbyXD1fWjz04QMKp59Ar1HNonmAkJeLj6A@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/68pSlNFMUT9D2SyBmnYMGI0T_K0>
Subject: Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2017 21:00:49 -0000

On Mon, 10 Jul 2017, Shumon Huque wrote:

> 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.
> 
>     https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00

I'm not a fan :)

 	This means that DNS servers have to send responses with signatures of
 	all algorithms that the requested data are signed with, which can
 	result in significantly large responses.

This seems to be a pretty small use case. And it is the only one
mentioned in the introduction. It only affects zones that are in
algorithm rollover, unless you want to run zones that permanently sign
using multiple algorithms, but that's not a use case mentioned.

For any caching nameserver with multiple clients, there will be no gain
for the next 10 years, as it only takes 1 old client not using this
option to cause the caching nameserver to refetch (adding more bandwidth
usage)

You explain all this is vulnerable to a downgrade attack. And the
clients SHOULD (not MUST?) check the algorithms used in the DNSKEY
RRset. If the client can do that, why bother with a new EDNS0 option
to begin with? (I think the answer is "because an exiting DNSKEY might
be in the DNSKEY RRset, but no longer in use" but that would also affect
the downgrade attack then)

Since you need to survive the DNSEY RRset size, most of the introduction
explaining how this is to survive packet size matters at all, you still
need to survive it.

I don't think response size during a KSK algorithm roll is an issue that
needs fixing.

>> Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to
>> would not be available for response signatures?

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

One would hope zones are migrated from "strong" to "even stronger"
algorithms, and not from "weak" to "strong enough", so I don't think
algorithm downgrade is ever an issue.

This draft gives me a feeling it is really about something else, keeping
long term dual signed zones out there. I don't think that we should
aim for that to become commonplace.

Paul