Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 07 June 2018 19:34 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 34D1B131175 for <dnsop@ietfa.amsl.com>; Thu, 7 Jun 2018 12:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 ZE5Xf5_zRTag for <dnsop@ietfa.amsl.com>; Thu, 7 Jun 2018 12:33:57 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C5E131187 for <dnsop@ietf.org>; Thu, 7 Jun 2018 12:33:56 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9728B7A330A; Thu, 7 Jun 2018 19:33:55 +0000 (UTC)
Date: Thu, 7 Jun 2018 19:33:55 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20180607193355.GF3322@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <152822474090.19277.2490524843716126021.idtracker@ietfa.amsl.com> <D1867A13-540C-4154-B70A-C057428DFA26@isc.org> <20180607063933.GD3322@mournblade.imrryr.org> <alpine.LRH.2.21.1806071357470.31594@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.21.1806071357470.31594@bofh.nohats.ca>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PRwAMHfM7ytLSSLRTgU_OIva_2g>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 19:34:08 -0000

On Thu, Jun 07, 2018 at 02:02:23PM -0400, Paul Wouters wrote:

> >    And furthermore, on 64-bit systems SHA512 tends
> >    to be somewhat faster (more with larger input sizes), because
> >    it processes input in 64-bit blocks.  On my x86_64 laptop,
> >    running OpenSSL 1.1.1 beta 'speed -evp', gives:
> 
> At the time, we were more concerned about packet size than CPU usage.

The packet size for RSA algorithms depends only on the modulus,
not the underlying hash function, which just needs to generate
hashes slightly shorter than then modulus.  With RSA keys of 1024
or more bits, SHA256 and SHA512 both fit, and produce signatures
of the same size.

> >    So I am not sure that algorithm 10 warrants discouragement so
> >    long as 8 is required.  Everyone is going to have both, and
> >    they're basically the same...  While the case *for* 10 is not
> >    strong, the case against 10 looks somewhat weak (does supporting
> >    10 for signing carry a real cost?)
> 
> I hope it is now clearer why we are doing this?

Well, I see that we end up with a bit less code-point diversity,
but in this case 8/10 are barely different and require the same
supporting code.  So while I'm not strongly advocating 10, I see
it just a "tweak" of 8, and would expect to not differentiate
between them, use either, interoperate with neither or both...

Again, this comment is not an objection just saying that I would
have treated 8 and 10 as interchangeable.

-- 
	Viktor.