X-Original-To: bind9-public@bugs.isc.org Return-Path: In-Reply-To: content-type: text/plain; charset="utf-8" X-RT-Interface: Email Date: Sat, 26 Aug 2017 11:48:43 +0530 To: "Evan Hunt via RT" 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)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 59BADD78AF0 for ; Sat, 26 Aug 2017 06:18:57 +0000 (UTC) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by mx.pao1.isc.org (Postfix) with ESMTP id E28FD34BB29 for ; Sat, 26 Aug 2017 06:18:53 +0000 (UTC) Received: from jurassic (unknown [115.118.63.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 0B53756A06BC; Sat, 26 Aug 2017 06:18:49 +0000 (GMT) X-RT-Incoming-Encryption: Not encrypted Delivered-To: bind9-public@bugs.isc.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 User-Agent: Mutt/1.8.3 (2017-05-23) From muks@isc.org Sat Aug 26 06:18:57 2017 X-RT-Original-Encoding: utf-8 MIME-Version: 1.0 Message-ID: <20170826061843.GA27711@jurassic> From: "Mukund Sivaraman" Subject: Re: [ISC-Bugs #44755] Remove the default hash setting for RSA in 9.12 References: <20170821015118.GA13540@jurassic> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org Content-Disposition: inline RT-Message-ID: Content-Length: 1505 Hi Evan On Thu, Aug 24, 2017 at 08:48:16PM +0000, Evan Hunt via RT wrote: > On Mon Aug 21 01:51:38 2017, muks wrote: > > Don't introduce the RSA256 and RSA512 mnemonics as 256 and 512 are > > associated with SHA-2 family of hash functions and are confusing with > > just RSA. > > Fair point. My thought was, even though there's no standards support for > abbreviations, it would improve usability with the longer and harder-to- > remember algorithm names, but you're right those are ambiguous and should > go. I've pushed that change now. > > Are you okay with ECDSA256 and ECDSA384, though? I find the full expansions > of those algorithms almost impossible to remember and usually have to look > them up and then cut and paste. But if you object I'll remove the abbreviations > for those as well. In the case of ECDSA algorithms, the hash output and public key sizes match. I'm not pushing it, but if you ask for my opinion, I'll say just stick to the IANA table mnemonics. There could be an ECDSA SHA-3 combination with matching sizes again, to prepare if something happens to SHA-2, but it's unlikely there'll be any other combinations. An admin looking to use these would look for the standard algorithm mnemonic instead of a BIND specific one. If short forms are desired, better to ask for it on dnsop@ and get more opinion on it, and it will also be the same across implementations if it gets into the table. Anyway you're aware of what the concern is, so use your judgement. :) Mukund