Re: [DNSOP] [Ext] DNSSEC Strict Mode

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 26 February 2021 19:20 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D68DE3A1563 for <dnsop@ietfa.amsl.com>; Fri, 26 Feb 2021 11:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 YfsdDrT_2yWj for <dnsop@ietfa.amsl.com>; Fri, 26 Feb 2021 11:20:39 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 8D3E33A1562 for <dnsop@ietf.org>; Fri, 26 Feb 2021 11:20:39 -0800 (PST)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id BCD7CC23D9 for <dnsop@ietf.org>; Fri, 26 Feb 2021 14:20:38 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CA+nkc8D4aC30ooepVDUewU_rSqh1XaBa2qCgE7izuEBALXczSw@mail.gmail.com>
Date: Fri, 26 Feb 2021 17:20:38 -0200
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <4AFB7838-69EA-4F25-9084-E27141E6015F@dukhovni.org>
References: <CAHbrMsBeCiZ-31hjKvet2UPDPFhdVYpgqR6Kw-WWz1ERgeSFoQ@mail.gmail.com> <B2CF080D-7513-4414-9316-9999AF441F43@icann.org> <CAHbrMsAdbn85AUCY9Yr6XXU-6Ti4dKwR1=zncGj4z-SjznAF3w@mail.gmail.com> <76A8C023-AB7D-4D50-BE85-B1BAFDD3FBD4@icann.org> <CA+nkc8D4aC30ooepVDUewU_rSqh1XaBa2qCgE7izuEBALXczSw@mail.gmail.com>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IZtZy4YoOjFqQmrPlJqFRpT0W3U>
Subject: Re: [DNSOP] [Ext] DNSSEC Strict Mode
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 26 Feb 2021 19:20:42 -0000

> On Feb 26, 2021, at 1:06 PM, Bob Harold <rharolde@umich.edu> wrote:
> 
> If you sign your zone with several algorithms, and mark them all 'Strict", you are asking my resolver to do extra work.  I will probably configure my resolver to only validate with one algorithm.  Maybe the strongest, maybe the least cpu intensive, my choice, not yours.

In terms of downgrade resistance, that's just fine.  The signal
should not be interpreted to require the resolver to check them
all, or any particular one.  Rather, it would indicate that you're
free to conclude there's an attack and fail, if your preferred
strict algorithm is not included in the set of returned signatures.

This is sufficient to protect against downgrades from whatever
algorithm you would have chosen if you had them all, to some other
one that you would not have chosen.

One could also take the view that all the algorithms are equally
good, and ignore the signal, though if I saw a promise of P256 + RSA,
and got back just a 512-bit RSA signature, I'd be reluctant to
conclude that it is as strong as the missing P256 signature... :-)

So, in principle the proposal is a fairly natural anti-downgrade
mechanism.  The main question is whether this is plausibly needed,
and here I am not so sure.  I'd prefer to instead see more attention
to avoiding weak parameters.

This looking at SHA-1, we need to:

  * Phase out DS hash algorithms 1 (and outdated GOST 3)

  * Phase out DNSKEY algorithms 5 and 7.

Looking RSA-base DNSKEY algorithms, the the most widely used
RSA key sizes are: 

             # domains  key bits
             ---------  --------
             7,972,397      2048
             7,342,144      1024
               122,529      4096
                22,678      1280
                13,763      1536
                 8,273       512
                 1,502     Other [1]

I would therefore propose that we:

  * Update the RSA-based algorithms to require keys of
    at least 1024 bits and at most 2048 bits.

  * After the sunset date, shorter keys are treated the
    same way as unsupported algorithms (zone is unsigned).

  * After the sunset date, longer keys are treated as
    signature verification failure!  For better security
    than RSA-2048, use P256 or Ed25519.

  * Set a sunset date for KSKs shorter than 1536 bits,
    after which time KSKs with < 1536 bits are equivalent
    to unsigned.

  * Strongly recommend ZSKs of at least 1280 bits, and update
    defaults in signing tools to be 1280 bits, if currently
    set to 1024-bits.

  * Recommend 1280 bits for ZSKs.

  * Recommend 2048 bits or 1536 bits for KSKs

  * Require the RSA exponent to be one of the 4
    used in the wild that are not outright errors:

          2^2^4 + 1     = 0x10001 = 65537      (8,126,993 domains)
          2^2^30 + 3 = 0x40000003 = 1073741827 (   29,398 domains)
          2^2^0 + 1               = 3          (      218 domains)
          2^2^5 + 1 = 0x100000001 = 4294967297 (       21 domains)

	  [ https://stats.dnssec-tools.org/ ]

    possibly just the first 3, the 21 domains using 2^2^5+1 can
    migrate to a more sensible exponent.

Improving practices in this space will do a lot more to improve
DNSSEC security than downgrade-resistant key algorithm signalling.

-- 
	Viktor.

[1] Full RSA key bit size frequency table:

   7972397 2048
   7342144 1024
    122529 4096
     22678 1280
     13763 1536
      8273 512
       345 1028
       299 2304
       268 2560
       124 2024
       114 1300
        99 3072
        72 2047
        34 1023
        22 1152
        17 768
        12 1350
        12 1550
        12 1048
        10 2046
         4 2014
         4 2096
         3 4086
         3 2044
         3 2045
         3 1304
         3 2112
         3 1400
         2 4095
         1 1475
         1 1483
         1 1527
         1 1530
         1 1294
         1 1972
         1 1984
         1 256
         1 1292
         1 2028
         1 2038
         1 2043
         1 1291
         1 1283
         1 1248
         1 1014
         1 2119
         1 1155
         1 2319
         1 2480
         1 1080
         1 1042
         1 3096
         1 3968
         1 4075
         1 4092
         1 1336
         1 1330
         1 1345
         1 1315
         1 1430
         1 1444
         1 1455
         1 1456