On Fri, 5 May 2017, Olafur Gudmundsson wrote:
I strongly advocate against the adoption of this document in current from.
It violates basic interoperability guidelines by defining way to many
algorithms with no justification why any of them are better or worse than
others.
There is no useful guidance on why these new algorithms are better even among
themselves.
One of the biggest hurdles to deployment is not in the 5-20 DNS software
packages in wide use; but in all the 1000’s of Provision
systems around the world,
and the crypto libraries found on various Enterprise systems that have life
time of 4-8 years with security-only updates.
Lets learn the lessons documented in
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04
I’m not convinced that SHA3 vs SHA2 matter at all given the constraint small
data with strict constraints on order and contents is
being signed.
I agree. Especially in the light of how hard it is to remove obsolete
algorithms. We should have very good reasons to add new ones.
The RSA KEY size allowed for these new supposed stronger Digest algorithms is
still left at 1024 or 1280 bytes, even though number
of other parts of the the Internet community will not consider signatures by
keys with less than 2048 bits.
Not only that, but the reason specified is to bump RSA from
RSASSA-PKCS1-v1_5 to RSASSA-PSS. As far as I know, the security
issues of RSASSA-PKCS1-v1_5 are that when using it to _encrypt_
bogus data, it can be used as an oracle to obtain private key
bits. That means there is no on-the-wire security issue with
RSASSA-PKCS1-v1_5 for Digital Signatures. And if HSMs are used
to protect access to private keys, those keys should be marked
as "signing only keys" to avoid exposing the private key via this
attack if the machine with the HSM is compromised.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
