Re: [DNSOP] RSASHA512 SHOULD-
On 11 Apr 2016, at 12:34, Evan Hunt wrote: On Mon, Apr 11, 2016 at 03:15:47PM -0400, Paul Wouters wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSASHA512 SHOULD-
On Mon, Apr 11, 2016 at 03:15:47PM -0400, Paul Wouters wrote:
> 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.
> 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.
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.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSASHA512 SHOULD-
On Fri, 8 Apr 2016, Evan Hunt wrote:
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.
I understand, and we don't want to break existing installations, but
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
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
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.
Based on the above stats, I'd still prefer it to go away completely.
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.
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSASHA512 SHOULD-
On 8 Apr 2016, at 10:46, Francis Dupont wrote: 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? 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSASHA512 SHOULD-
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 -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSASHA512 SHOULD-
On Fri, 8 Apr 2016, Francis Dupont wrote: 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 (:-)! 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RSASHA512 SHOULD-
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 francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
