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

Shumon Huque <shuque@gmail.com> Mon, 10 July 2017 23:44 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 A3851120726 for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 16:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: 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 fWBfpu-N7xqw for <dnsop@ietfa.amsl.com>; Mon, 10 Jul 2017 16:43:59 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 176231200ED for <dnsop@ietf.org>; Mon, 10 Jul 2017 16:43:59 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id r125so56506870vkf.1 for <dnsop@ietf.org>; Mon, 10 Jul 2017 16:43:59 -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=QhvEKy1PcCrcHLoF2lpNi2QcyG8x8naEGnoZhlSiKig=; b=tWoicQ6wR5744usG5OMmyo5HUVNG2Locy+Xi1uRsVsnMVbYNcOroI1iTPOLsOA+7wI UXdrEO23sMY2ee3FBxO4IUOuSHN770draHWLAqq88ryUYDNInK+EDqO3S+WT05KuyuoN E1rufo1yWwsg1uLXAYwetJ5nywd/TYuqNpQQdkQfgn/a0wHTHKhz0pOgb269BFrnLCdl UF6hrzLwREHLSVaziXb/VmIQmlIO4wadCJ1Lzkwl6Zb692SDdu3PZGULNUE73Abuqlcm MKuRxxKR/KKkQFeRBpXlZr14OErTjCV9KWhjAoLTvDKjsf/yxMPjYuQXyNVBgXh+A/f2 Wm6g==
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=QhvEKy1PcCrcHLoF2lpNi2QcyG8x8naEGnoZhlSiKig=; b=o1PyJiFBM/up37QaV+lpJZxI/hKzlfYRdfPgt1F7hYZlpAOQyY/jfiGG9DezLvlv9F jl/bm83RHU7AuGg6Ofc5qR/7NfAfpbLi4ZbL9dAXCZSesnM5+9n9y3vpVKypXOZgbYEQ qjBDy21BOcWfrHvbbFbWUolc6Jtpmbw6brb4wkN42fSL5wOnR/Hc5iEyI9Ma6uMlLZ7x 9wWEP32AhEv5VnQwJt14Pvb7a2igSzRZSY8KEHwL5x9s+NVYaVjwlwoReUEV79038xer ZrRXSm3yydM8W2dHV04l+/SnQjE6PDl0PlTV6BJBVCV2DxIVXH1HQRhFAZ3UWVOLxdpZ t42w==
X-Gm-Message-State: AIVw111/q/7wmiOxhpfbfd13gPbuFhJp6ZDwcgwBZz5gidCgAfmsAW6n hCaPZhjCWJefsun8yyZcc/cuderQgvAgxL4=
X-Received: by 10.31.136.9 with SMTP id k9mr8955631vkd.50.1499730238095; Mon, 10 Jul 2017 16:43:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.79.231 with HTTP; Mon, 10 Jul 2017 16:43:57 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.21.1707101840110.2811@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> <CAHPuVdVFyFrXxmpJg-hO0Wv_SD9FMpzYZjWtGFZeZA-9hFQaiA@mail.gmail.com> <alpine.LRH.2.21.1707101840110.2811@bofh.nohats.ca>
From: Shumon Huque <shuque@gmail.com>
Date: Mon, 10 Jul 2017 19:43:57 -0400
Message-ID: <CAHPuVdXKPrNO9WiAx5pa=D1jfUniBL7ONNK9=V4LnUNUQaipxg@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a11441d7419c4840553ff2835"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MSbY12_1yc9RzzzotoUnyJg5CTQ>
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 23:44:02 -0000

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

> On Mon, 10 Jul 2017, Shumon Huque wrote:
>
>>
>> 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.
>>
>
> Okay, that explains it better. but does also confirm you basically want
> to be permanently in this state. Because every few years you will have
> new fancy algorithms. As a community we should really roll out updated
> algorithms faster and deprecate obsoleted algorithms faster.


I certainly agree with that goal. In practice it is hard to achieve given
the vast population of DNS software and the long tail of feature adoption.

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.
>>
>
> But then why not depend on adoption of (and deprecation of) old signing
> algorithms?


That would be ideal. Again desire vs reality. In this case, the earlier
deployers of multiple algorithms are bearing the costs, and would expect to
gain the benefits of selective signature delivery slowly over time. Of
course they are imposing costs in terms of larger responses on everyone
else too, but they would be doing that even without this feature.

This feature is really looking longer term - and hoping to prepare us
better for the introduction of new algorithms in the future. If this gets
implemented, even if no-one initially uses it, we might be prepared for
future iterations of new algorithms (like various post quantum algorithms
or something else).


>       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.
>>
>
> You are mixing up keysize and algorithm rollover :P
>

I was mainly disputing your remark about hoping there are no "weak"
algorithms :-)

I realize that keysize upgrade could address this, but so also could
rolling to a stronger algorithm like ECDPSAP256.


> RSA is not broken, and safe to use, preferably at 2048 key size. No double
> signing or algorithm signaling is needed to go from RSA1024 to RSA2048 :)
>
> also: https://www.internetsociety.org/doc/state-dnssec-deployment-2016
>
>         "The overwhelming majority (~99%) of TLDs use 2048 bit keys"
>
> I can't find a statistics URL for all domains (secspider seems to have
> changed and I cannot find the RSA key sizes per domain anymore) but I'm
> pretty sure 1024 will be on the decline.
>

You're only as strong as your weakest link. The weak link in almost all
deployed DNSSEC paths today is RSA1024. Your 2048-bit figure is for KSKs.
Most zone data is signed with RSA1024. Here are my current stats of TLD
keysize distribution:

Key Signing Keys (KSK):
1024 bits: 1 (0.0%)
1280 bits: 5 (0.2%)
1536 bits: 1 (0.0%)
2048 bits: 2022 (98.8%)
4096 bits: 17 (0.8%)

Zone Signing Keys (ZSK):
1024 bits: 1566 (69.7%)
1048 bits: 2 (0.1%)
1152 bits: 5 (0.2%)
1280 bits: 537 (23.9%)
2048 bits: 138 (6.1%)

So roughly 70% of TLDs sign zone data with RSA1024.


> Anyway, my point is that we should not have 20 sexy algorithms, but only
> a very limited set of a few algorithms that we all agree are strong enough.


Yes, I am in total agreement. We should as few strong ones as possible. But
that's still more than one.

Some crypto folks are now advocating for new protocols, define only one
cipher family and don't negotiate. But in reality, deployed protocols that
evolved over time have many, and correspondingly have a cipher negotiation
mechanism. TLS has something on the order of 100 cipher suites last time I
looked.

-- 
Shumon Huque.