Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update

Ondřej Surý <ondrej@isc.org> Tue, 23 October 2018 17:51 UTC

Return-Path: <ondrej@isc.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 88B33128C65 for <dnsop@ietfa.amsl.com>; Tue, 23 Oct 2018 10:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.921
X-Spam-Level:
X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, 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 c4SqTwqEvnjz for <dnsop@ietfa.amsl.com>; Tue, 23 Oct 2018 10:51:10 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 B37511274D0 for <dnsop@ietf.org>; Tue, 23 Oct 2018 10:51:10 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4B6573AB067; Tue, 23 Oct 2018 17:51:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 16C6C160042; Tue, 23 Oct 2018 17:51:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0249C160076; Tue, 23 Oct 2018 17:51:09 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MEvk-yEboiHN; Tue, 23 Oct 2018 17:51:08 +0000 (UTC)
Received: from [10.10.0.181] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id EE192160042; Tue, 23 Oct 2018 17:51:07 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.100.43\))
From: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>
In-Reply-To: <20181022.004019.1615670116405060818.fujiwara@jprs.co.jp>
Date: Tue, 23 Oct 2018 19:51:05 +0200
Cc: =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat@nic.cz>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8ED3779C-0BF3-4836-BCD9-4C76A68CF514@isc.org>
References: <20181016.000457.1043014259425988884.fujiwara@jprs.co.jp> <20181018.061802.1574444586575789321.fujiwara@jprs.co.jp> <5d5e7513-fcb5-04b2-ba53-60ab9ab8b193@nic.cz> <20181022.004019.1615670116405060818.fujiwara@jprs.co.jp>
To: "fujiwara@jprs.co.jp" <fujiwara@jprs.co.jp>, Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.100.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JrnSX054G9EROxpe-uI0_r7kDus>
Subject: Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
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: Tue, 23 Oct 2018 17:51:12 -0000

> On 21 Oct 2018, at 17:40, fujiwara@jprs.co.jp wrote:
> 
>> From: Vladimír Čunát <vladimir.cunat@nic.cz>
>> On 10/17/18 11:18 PM, fujiwara@jprs.co.jp wrote:
>>> 4. In my opinion, Ed25519 is best algorithm some yars later.
>>>   If the document describes both current RECOMMENDATIONS and
>>>   RECOMMENDATIONS some years later, we can plan.
>> 
>> 
>> I agree, but the last paragraph of 3.1 seems to express that already:
> 
> Yes.
> 
> # I'm afraid that some TLD/Root operators may not support ED25519
> # because it is RECOMMENDED (not MUST).

The I-D already says:

>    It is expected that deprecation of an algorithm will be performed
>    gradually.  This provides time for various implementations to update
>    their implemented algorithms while remaining interoperable.  Unless
>    there are strong security reasons, an algorithm is expected to be
>    downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST
>    NOT.  Similarly, an algorithm that has not been mentioned as
>    mandatory-to-implement is expected to be introduced with a
>    RECOMMENDED instead of a MUST.

and the last paragraph of 3.1 explicitly says:

>           It is
>           expected that ED25519 will become the future RECOMMENDED
>           default algorithm once there's enough support for this
>           algorithm in the deployed DNSSEC validators.

I don’t think more handholding would be appropriate of IETF RFC.

Thanks for all the comments,
--
Ondřej Surý
ondrej@isc.org