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

Shumon Huque <shuque@gmail.com> Mon, 10 July 2017 21:59 UTC

Return-Path: <shuque@gmail.com>
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 AC3D413191A for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 14:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2GZaM12Hd1LH for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 14:59:20 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F233112F27C for <dnsop@ietf.org>; Mon, 10 Jul 2017 14:59:19 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id w19so63637962uac.0 for <dnsop@ietf.org>; Mon, 10 Jul 2017 14:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jkK5Oj0KWG4Chw2ZwBEmUKgepQ5fsF8/fieMb5AlUQU=; b=RuGSNsXUeNuQCQdHky9b+1SgUZkvYYC8y49I5tg/L+CBNIxtjF8FCooDlBpHQVUHrl 01LSZUg4UMaDQg38vhkg5wJHcmtrOl8yn4k3GKLklwPr4RX9v7bXHPwtmEGblIvxC2dJ 8x9avKOPVr2Aw4Gu3BnHmeK2qqpwYWr0ixeUUpFhcABvwgTW7dg2tOAuGVoE3S+IlSGR ilKo+fRzwOBqess9bJPUl8vqzwGU1FV3ioNkzg64GPmWvrKBF1rWYwgvkga66bNSHBlJ rpV4BVhpIjMzYUXhcToGxNuU7rdNjRgLLGuweTs2FLBSgeGk2l//4BsVUNaFvOZ4Oydl MGtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jkK5Oj0KWG4Chw2ZwBEmUKgepQ5fsF8/fieMb5AlUQU=; b=s3kIjiff9mfc1H8CIBMOl+oKBPVTYqq+UJwlwoQwwLyeqKtoyfqaKk6FVe3XZWn+9a ts+ELnyOpKc6H/eabLvS9prohvLWMWZ8WtAyOi+NoCJWE8EWlLRVCWaFw1QBc5a8JcQg qNDECnKdUfiYEt2Y9yr2ZtJH0h2DyBv7zXLGKwRoN+2IiSpl4lV/BOZqFmACA3SGX9V+ 4KHzbuNn0dyswAFaOCP7FN2giWkeG4Xg4Z+Zh9oF518E4zNkRaTwKU7SwpvxeZbvms+L LH2FMpHWBBLPtl6J7o7n8i+w5hhtSfoy4YN9+UYmPp5Bf/5MVNHiujDYcz24m5TLRn0b Cfcw==
X-Gm-Message-State: AIVw1102ydhZZRF2gSNumanoqN7QLrrbustZfWZRzhdfahKaCKn7Kxz9 nhgFRPV/ZAy9qa/0DTTko6lmOZzvPQ==
X-Received: by 10.176.86.21 with SMTP id y21mr8812806uaa.72.1499723959092; Mon, 10 Jul 2017 14:59:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 14:59:18 -0700 (PDT)
In-Reply-To: <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> <alpine.LRH.2.21.1707101641220.31889@bofh.nohats.ca>
From: Shumon Huque <shuque@gmail.com>
Date: Mon, 10 Jul 2017 17:59:18 -0400
Message-ID: <CAHPuVdVFyFrXxmpJg-hO0Wv_SD9FMpzYZjWtGFZeZA-9hFQaiA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Bob Harold <rharolde@umich.edu>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045dd5b0d7d11d0553fdb193"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_4AqIyQFjq0hKOaEBJpkbP8dNe4>
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:59:23 -0000

On Mon, Jul 10, 2017 at 5:00 PM, Paul Wouters <paul@nohats.ca>; wrote:

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

Perhaps we didn't explain it clearly enough, so let me give you a concrete
example:

My zone is currently signed with 2048-bit RSASHA256. I want to offer
signatures with Ed448 (or some other new algorithm) also, so that newer
validators can take advantage of it. However, I want to be able to continue
to support the current population of validators that don't support Ed448
until a sufficient amount of time has passed where they have all been
upgraded - this could be some number of years.

I also don't want to double sign the zone and return multiple signatures in
the responses, because they might be fragmented and cause timeouts and
retransmissions at the client (validator) end. I could truncate those
responses and prompt them to re-query over TCP, but then again I have
caused an unnecessary failed roundtrip and have incurred additional
processing costs associated with TCP, and maybe I haven't scaled up my
authoritative infrastructure sufficiently to deal with that.

I also don't want to deploy only Ed448 and cause my zone to be instantly
treated as unsigned by the vast majority of resolvers. Obviously, because
I've nullified the security benefit of DNSSEC, but also because I have
application security protocols, like DANE, that critically depend on DNSSEC
authentication, for which this would pose a grave security risk.

So the goal is not to have them "permanently" signed with multiple
algorithms, but for a defined transition period, which may not be very
short. At that point, the older algorithm would be withdrawn -- so
algorithm rollover, but over an extended period.

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.


Yes, that should have been a MUST (I made a note of that already for the
next revision).


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

Of course there are initial costs. The goal is longer term - the benefits
will increase with more adoption over time. There will be a lot of large
responses initially, which will decrease over time.


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

Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is
the butt of jokes in the larger security community.


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


See the first example I gave. We're not trying to surreptitiously sneak in
a use case.

-- 
Shumon Huque