[DNSOP] Updating draft-muks-dnsop-dnssec-sha3-01

Mukund Sivaraman <muks@mukund.org> Fri, 17 May 2019 02:18 UTC

Return-Path: <muks@mukund.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 45BD712033D for <dnsop@ietfa.amsl.com>; Thu, 16 May 2019 19:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 75LhtN5EWr-R for <dnsop@ietfa.amsl.com>; Thu, 16 May 2019 19:18:10 -0700 (PDT)
Received: from mail.akira.org (mail.akira.org [IPv6:2a01:4f8:13b:607::228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E410D120168 for <dnsop@ietf.org>; Thu, 16 May 2019 19:18:09 -0700 (PDT)
Received: from jurassic.lan.banu.com (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.akira.org (Postfix) with ESMTPSA id B1FF67900315; Fri, 17 May 2019 02:18:07 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1558059488; bh=2BNHTm9AonIGy8rMEP1ZBfyy4oVLh7Su9F4upboDBqA=; h=Date:From:To:Subject:From; b=FVY5ItXgWRPxb281MrBdyP3IUK+Vijz22P/zTb3xRt3Ni2kNgwK4QPfBX4Ub+skCs n4GPonV6ylR/TD+Zli8dYzVS0ktD8vHZzpWZO9MZdH2B+F/ZGXOSyBLcA3RhGAptXr rX4lMNeh4LuhPJrPHfb6+Rj+Cz36ZIzUnigB/8Dc=
Date: Fri, 17 May 2019 07:48:05 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: dnsop@ietf.org
Message-ID: <20190517021805.GA28277@jurassic.lan.banu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.11.3 (2019-02-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Sfx4wdy7NPCk2GREI1eggUO6qe4>
Subject: [DNSOP] Updating draft-muks-dnsop-dnssec-sha3-01
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: Fri, 17 May 2019 02:18:12 -0000

Hi everyone

Sometime ago, Jelte and I had submitted SHA-3 variants for existing
DNSSEC algorithms along with working code (for BIND and ldns
library). At that time, many of the reviewers felt that continuing to
include use of RSA signatures (though it was upgraded to the PSS form)
in new algorithms was redundant considering the migration to ECC
algorithms in the DNS industry. Though short-lived short-length RSA
signatures are still used in the DNS, the adoption of ECC algorithms has
been largely successful.

SHA-1 is getting weaker by the passing of time, and the SHA-2 family is
the last remaining deployed family of DNSSEC hash functions. It takes
time for new algorithms to trickle down into deployed software, and
introducing an alternative early is sensible.


Please read the introduction section (page 3) for info on SHA-3 as it
compares to SHA-2.

Would there be consensus if the draft is updated to specify SHA-3 for
just a subset of ECC algorithms? Should it be specified for all of
[ECDSAP256SHA256, ECDSAP384SHA384, ED25519, ED448] or a subset of them?