Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt

Mukund Sivaraman <muks@isc.org> Wed, 05 April 2017 14:50 UTC

Return-Path: <muks@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 9C4CF126DC2 for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 07:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 qGoOdatoroPg for <dnsop@ietfa.amsl.com>; Wed, 5 Apr 2017 07:50:17 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1337E1250B8 for <dnsop@ietf.org>; Wed, 5 Apr 2017 07:50:17 -0700 (PDT)
Received: from jurassic (unknown [115.118.28.247]) (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 9974756A0366; Wed, 5 Apr 2017 14:50:14 +0000 (GMT)
Date: Wed, 05 Apr 2017 20:20:10 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: dnsop@ietf.org
Message-ID: <20170405145010.GA29337@jurassic>
References: <20170405084256.GA22692@jurassic> <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP"
Content-Disposition: inline
In-Reply-To: <39B58207-4CC2-420B-B774-2766FC80B194@vpnc.org>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B2P50edC5CBg3v7gvAiAUgNDSjI>
Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 05 Apr 2017 14:50:19 -0000

Hi Paul

On Wed, Apr 05, 2017 at 07:24:11AM -0700, Paul Hoffman wrote:
> On 5 Apr 2017, at 1:42, Mukund Sivaraman wrote:
> 
> > > Name:		draft-muks-dnsop-dnssec-sha3
> 
> NIST's use case for SHA3 algorithms is for when particular SHA2 algorithms
> are weakened. This would mean that the fallback for RSASHA256 is RSASHA512,
> not a SHA3 variant. Thus, the premise for this entire draft (which isn't
> listed until the end...) is flawed.

From FIPS 202:

"The four SHA-3 hash functions in this Standard supplement the hash
functions that are specified in FIPS 180-4 [1]: SHA-1 and the SHA-2
family. Together, both Standards provide resilience against future
advances in hash function analysis, because they rely on fundamentally
different design principles."

From the NIST press release:

"SHA-3 is very different from SHA-2 in design," says NIST's Shu-jen
Chang. "It doesn't replace SHA-2, which has not shown any problem, but
offers a backup. It takes years to develop a new standard, and we wanted
to be prepared in case problems do occur."

Though RSA/SHA-256 vs. RSA/SHA-512 doesn't affect RRSIG lengths, there's
the case of DS digest size where the fallback for SHA-256 would be
SHA3-256 because SHA-512 is longer.

SHA-512 hashing is known to be faster than SHA-256 on popular commodity
hardware on inputs larger than a few bytes long, and though the
algorithms are different, they are more siblings w.r.t. analysis. E.g.,
see the table below where each attack affects both SHA-256 and SHA-512:

https://en.wikipedia.org/wiki/SHA-2#Cryptanalysis_and_validation

> Also, it is weird that a draft that is about having a fallback if a hash
> algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme,
> given that PKCS1 1.5 is already known to be weakened.

It was to allow simple addition of the algorithm to existing
implementations. However, in light of your comment, we'll discuss
revising it.

		Mukund