[DNSOP] minor update to draft-wouters-sury-dnsop-algorithm-update

Paul Wouters <paul@nohats.ca> Tue, 11 October 2016 17:29 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 B0211129591 for <dnsop@ietfa.amsl.com>; Tue, 11 Oct 2016 10:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.996
X-Spam-Level:
X-Spam-Status: No, score=-4.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.996] 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 ciFs4cA96AKP for <dnsop@ietfa.amsl.com>; Tue, 11 Oct 2016 10:29:22 -0700 (PDT)
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 6B76512952B for <dnsop@ietf.org>; Tue, 11 Oct 2016 10:29:22 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3stkWN3jh1z3Td for <dnsop@ietf.org>; Tue, 11 Oct 2016 19:29:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476206960; bh=i+UQLhxCTiGsXGiCTz9lyJIE9jBFAS1QxTVGLnsnj8Q=; h=Date:From:To:Subject; b=S3AhGVf2zj0+S4tfRxkdpFQJVg+uKNPLu1foa7w4MdIXUELbOz0mG1BIfUoQYwTfr D6PkgVWasgcValVG+yUuxg0ajEF3ymJSfScbYbaA5X2R3z0+J2H7HKKFcoPaexzJQH ii5gfVSGqgrYnyIm+Ol5MdRMVWyEOOA6Q6jo6o0M=
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 VJqVSgxB9lEt for <dnsop@ietf.org>; Tue, 11 Oct 2016 19:29:18 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Tue, 11 Oct 2016 19:29:18 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CECE33797DA; Tue, 11 Oct 2016 13:29:16 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CECE33797DA
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CB1C140D3586 for <dnsop@ietf.org>; Tue, 11 Oct 2016 13:29:16 -0400 (EDT)
Date: Tue, 11 Oct 2016 13:29:16 -0400
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
Message-ID: <alpine.LRH.2.20.1610111324050.30908@bofh.nohats.ca>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QDNY0h6hye5EGp0cItoyuxwrBZg>
Subject: [DNSOP] minor update to draft-wouters-sury-dnsop-algorithm-update
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 11 Oct 2016 17:29:24 -0000

(not sure why I didn't see an email yet)

I made some small changes to draft-wouters-sury-dnsop-algorithm-update

https://tools.ietf.org/rfcdiff?url2=draft-wouters-sury-dnsop-algorithm-update-02.txt

- Give a little more preference in favour of the EdDSA upcomimg
   algorithms at the expense of the ECDSA ones.
- Made ECC-GOST a little more consistent between signing and resolving.
- Updated references

The biggest issue that came up in previous discussions, is that at least
one vendor stated they will "never" remove signing support for certain
algorithms as to not break existing deployments, which would significantly
slow down deprecation of obsolete algorithms. But I don't think there is
anything that this document could change to that, other than hoping new
implementations will just skip implementing those algorithms.

Paul