Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Paul Wouters <paul@nohats.ca> Wed, 06 January 2021 21:20 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 1AC2D3A1271 for <dnsop@ietfa.amsl.com>; Wed, 6 Jan 2021 13:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 wEQja8h1GGvb for <dnsop@ietfa.amsl.com>; Wed, 6 Jan 2021 13:20:00 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 653763A126B for <dnsop@ietf.org>; Wed, 6 Jan 2021 13:20:00 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DB2M23BdfzCWV; Wed, 6 Jan 2021 22:19:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1609967998; bh=gbroHz6XjGO1wFj8tl25WPFMvp5U/+4UflTX1vY5B2A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RASXRl3cIXl+FeEiCGsmn8K34n1JcVgzYCqFzZcw6e7T8eEJ99H6K6g43xBuhblZI zzRdnsdfDeETkiene8v1qtpp/hqAdxphX9XgrZxiKrPfvHSc+7ymKPL6Pv+0GwMe4S ATuUgGcejf1UX1ResmIcoQHTKBb4BU/lfKUArK7U=
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 wtiInrIh1feR; Wed, 6 Jan 2021 22:19:57 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 6 Jan 2021 22:19:57 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1E9286029A47; Wed, 6 Jan 2021 16:19:56 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 160E966B7C; Wed, 6 Jan 2021 16:19:56 -0500 (EST)
Date: Wed, 06 Jan 2021 16:19:56 -0500
From: Paul Wouters <paul@nohats.ca>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <CAHbrMsDAMsXzAhcu35_GqL54JNF2jO-HhYWEZyE2VLP=V8dN5A@mail.gmail.com>
Message-ID: <47a8a8df-c4d8-78e-ec5e-cfdc6daea130@nohats.ca>
References: <CADZyTkn1QuvjencR8+wVtQ9bzQHJT9JXXNku1LPr3YRmRt4KQg@mail.gmail.com> <CABcZeBMr5Muijx5V7Se1UcxTB9DbAzF1iXZb7_FzEGfw982x8w@mail.gmail.com> <65e3288d-bdfe-ff10-2fbc-63a5d2dd9508@cs.tcd.ie> <797AAE77-2D50-4189-81D8-44BA495146F5@icann.org> <546e60c6-b109-8552-dfb4-7d3ba2ecbc71@cs.tcd.ie> <E58B4013-9491-43ED-83C9-250FF7647570@icann.org> <0746397c-ed85-429c-ff6e-a4a559520e86@cs.tcd.ie> <487928351.1557.1609759876775@appsuite-gw1.open-xchange.com> <60ba1f68-b07f-7a06-539f-60ce442ffbff@cs.tcd.ie> <195eb4c7-306f-97e1-b0df-f6678ebe732@nohats.ca> <ebb27f27-a243-67cd-2b5c-d2ecea741942@cs.tcd.ie> <24505bb1-cf40-25a7-337c-9b50fedfedc1@nohats.ca> <98299ffc-056b-16ee-1929-78543f5ec6d5@cs.tcd.ie> <F66DA99B-910E-4324-895D-F617B447612F@gmail.com> <CAHbrMsAqNXENeP2AdkEs7OC+YL6_z9VU89B7mNu3qOFBc7PQ=A@mail.gmail.com> <3a914ab5-2744-cec0-bbc8-bf39ec64a051@nohats.ca> <CAHbrMsDAMsXzAhcu35_GqL54JNF2jO-HhYWEZyE2VLP=V8dN5A@mail.gmail.com>
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/_AMg8ybSKKB2kvOBjol2W70bxlQ>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
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: Wed, 06 Jan 2021 21:20:02 -0000

On Wed, 6 Jan 2021, Ben Schwartz wrote:

>       Also, you would end up building a list of algorithms from worst to best.
>       This is not always obvious. Sure, the SHA1 vs SHA2 is obvious. Would you
>       prefer a NIST ECC curve over a GOST ECC curve or not?
> 
> TLS implementations always have a preference order, so I think this is doable.

To be fair, they kicked out everything except AES_GCM and CHACHA20POLY1305, and
I think any preference there is based on speed and not level of security :P

Remember also that TLS ciphers are negotiated. There is no negotiation
in DNSSEC. You get what is published and have to decide whether or not
to use it. So TLS clients have other options to avoid using ciphers they
don't like.

>  Literally any preference order
> would be more secure than the behavior recommended in RFC 6840.

Is it? Are you referring here to treating unknown (eg refused)
algorithms as insecure? The reason for that is to signal to the DNS
client that this answer had no "acceptable DNSSEC protection". This
is better than setting the AD bit on ciphers that you know and no longer
trust. Since that would signal to the application the answer was secured
by DNSSEC, but really it was not if you deemed the algorithm not
acceptable.

If you refer to what to do if one DNSKEY algorithm type is not working
and another algorithm type is, and what to do in such cases, then I
guess that behaviour is somewhat up to the client. unbound has an option
for this:

       harden-algo-downgrade: <yes or no>
               Harden against algorithm downgrade when multiple algorithms  are
               advertised  in  the  DS record.  If no, allows the weakest algo‐
               rithm to validate the zone.  Default is no.  Zone  signers  must
               produce  zones  that  allow  this feature to work, but sometimes
               they do not, and turning this option off avoids that  validation
               failure.


I guess that makes this discussion a variant of the Postel Principle is
good or bad discusion.

Paul