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

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Apr 2017 14:12:57 +0530

This was submitted today:

> A new version of I-D, draft-muks-dnsop-dnssec-sha3-00.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.

> Name:		draft-muks-dnsop-dnssec-sha3
> Revision:	00
> Title:		Use of SHA-3 (Keccak) Algorithms in DNSSEC
> Document date:	2017-04-04
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/internet-drafts/draft-muks-dnsop-dnssec-sha3-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-muks-dnsop-dnssec-sha3/
> Htmlized:       https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dnssec-sha3-00

> Abstract:
>    This document describes how to produce RSA/SHA3-256, RSA/SHA3-384,
>    and RSA/SHA3-512 DNSKEY and RRSIG resource records for use in the
>    Domain Name System Security Extensions ([RFC4033], [RFC4034], and
>    [RFC4035]).  It also describes how to produce SHA3-256 and SHA3-384
>    DS digest types.

An experimental BIND implementation is available here (sha3 branch):

https://github.com/muks/bind9/tree/sha3

The examples in the draft were generated using this implementation.

		Mukund

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Apr 2017 07:24:11 -0700

>> 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.

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.

--Paul Hoffman

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 5 Apr 2017 20:20:10 +0530

Hi Paul

On Wed, Apr 05, 2017 at 07:24:11AM -0700, Paul Hoffman wrote:
> 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

> 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

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 6 Apr 2017 10:37:33 +0200

> implementations. However, in light of your comment, we'll discuss

We can certainly discuss alternative schemes, RSASSA-PSS is a potential
alternative, which I understand is considered (much?) better. It has a
big drawback though, in that it requires salt, which can be a big issue
for large deployments.

An advantage would be that then we not only have an alternative within
the RSA family for SHA2, but also for the signature scheme itself.

Speaking of the use-case to pick up this work; IMO having more
cryptographic algorithms ready for use is generally a good thing; we
don't have to wait until the existing ones are completely broken :)

Jelte

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Apr 2017 13:54:28 +0100

> big drawback though, in that it requires salt, which can be a big issue

As I understand it the deterministic DSA trick (RFC 6979) also works for
RSA SSA PSS.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Plymouth, North Biscay: Easterly or northeasterly 4 or 5. Moderate,
occasionally rough at first in north Biscay. Fair. Moderate or good.