Subject: [DNSOP] RSASHA512 SHOULD-

From: Francis Dupont <[email-masked]>
Date: Fri, 08 Apr 2016 15:46:11 +0200

In draft-wouters-sury-dnsop-algorithm-update-01.txt the RSASHA512
(code 10) DNSKEY/RRSIG algo got a SHOULD- for DNSSEC signing.
The argument is it is not currently heavily used but I am afraid
it is not a very good argument.
I have a question for cryptographers in the list: as far as I know
there is a relationship with the RSA key size and the output length
of the hash algorithm. So perhaps we should not plan to move
RSASHA512 to MAY (or worse to MUST NOT) as the SHOULD- means,
i.e., put a SHOULD (vs SHOULD-) for RSASHA512?
Note the time the I-D will be published and applicable we likely
get a clearer view about this issue (:-)!

Regards

[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Apr 2016 10:18:06 -0400 (EDT)

> get a clearer view about this issue (:-)!

The reason behind our initial population of SHOULD- for RSASHA512 was
that:

- It is not used widely
- It causes much larger signatures for the same signature strength
   compared to the existing ECDSA algos and the imminent new EDDSA algos.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Fri, 8 Apr 2016 16:37:33 +0000

On this topic, I wasn't quick enough to get to the mic before the line was
closed, but I'd like to suggest a higher degree of caution with the "MUST
NOTs" and "MUST-'s" in the validator column, relative to the signer column.

IIRC, RSAMD5 was originally mandatory to implement.  I certainly don't mind
deprecating it for signing, but to tell validators that they not only don't
have to implement it, but actually MUST NOT do so, seems excessive.  The
only justiication I could see for that would be if MD5 were so
comprehensively broken that MD5-signed data could be trivially falsified,
and we're not there yet.  IMHO it shouldn't go any lower than MAY.

Similarly I think it's fine for {NSEC3,}RSASHA1 to get MUST- in the signer
column, but I don't see any near-term future where they should drop below
MUST in the validator column. It's still the default algorithm in the BIND
signer; it's going to be a long, long time before validators can start
ignoring it.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 08 Apr 2016 16:44:58 -0300

> i.e., put a SHOULD (vs SHOULD-) for RSASHA512?

There is a relationship between the effective strength of the key (RSA 
or EC) and the length of the output. If you are using 20,000-bit RSA 
keys, SHA512 might be appropriate. If you are using 4096 bit or shorter 
RSA keys, SHA256 is sufficient.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Apr 2016 15:15:47 -0400 (EDT)

> NOTs" and "MUST-'s" in the validator column, relative to the signer column.

I understand, and we don't want to break existing installations, but....

> have to implement it, but actually MUST NOT do so, seems excessive.  The

But we did not see much (any?) deployment of it. secspider shows just 19
of them. I will bet at least half of those are test domains.

http://secspider.verisignlabs.com/stats.html

> and we're not there yet.  IMHO it shouldn't go any lower than MAY.

Based on the above stats, I'd still prefer it to go away completely.

> signer; it's going to be a long, long time before validators can start

MUST- means you _must_ implement it, but it is expected to go to a lower
level in the future. The next revision of the doc could very well leave
it at MUST- if we don't see people moving to better algorithms. I'm
still somewhat optimistic that if popular signing software such as
opendnssec implements algorithm rollover, we might actually see many
migrations from RSASHA1{NSEC3} to RSASHA256.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Mon, 11 Apr 2016 19:34:54 +0000

> Based on the above stats, I'd still prefer it to go away completely.

I have no objection to eliminating it from signers, and it's okay
with me to leave it optional for validators, but that puts it to
the level of MAY, not MUST NOT. I don't think it should go to MUST
NOT unless merely *being able* to validate MD5 signatures is itself
dangerous, and I don't believe that's the case.

> migrations from RSASHA1{NSEC3} to RSASHA256.

Yes, I understood the meaning, but I have no hope or expectation that its
status (again, with respect to validators, not necessarily signers) will
change in any plausible near future. Call it MUST- in some future revision
when we've seen evidence of a switch taking place; hoping for it isn't
enough.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 11 Apr 2016 13:27:55 -0700

> dangerous, and I don't believe that's the case.

Evan has a good point here: if an algorithm is not actively harmful to a 
validator, anything lower than MAY seems inappropriate. The fact that a 
signing with an algorithm might expose the signer's private key (which 
is not the case here now, but could be in the future) is only a security 
risk for the signer, not for the validator.

So, +1 to no algorithms in the "validator" column being SHOULD NOT or 
MUST NOT.

--Paul Hoffman