Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01

[Paul Wouters <[e-mail]>]

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