On Mon, 29 Feb 2016 09:32:04 -0800 Joseph Salowey <j...@salowey.net> wrote:
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable > way forward or not. I recently already saw the message here asking for PKCS #1 1.5 compatibilty and was quite angry about it, but as there wasn't much discussion I thought this issue would go away. It seems it did not. RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. Therefore we can conclude: * Whoever created that hardware implementation either did so more than 13 years ago (probably unlikely) or deliberately created hardware crypto with sub-standard algorithm support. * This can mean a couple of things: a) The hardware vendor knew about it and expected that they could prevent a move to RSA-PSS by lobbying standardization bodies (this is what they seem to do right now). In this case they deliberately want to weaken security and that behavior should not be encouraged. b) They didn't know about RFC 3447. That probably means they shouldn't develop crypto products at all. c) Something else? whatever the reason was, I can't find any reason I would find in any way acceptable. I think the TLS working group should not encourage such vendor behavior. Instead I think the opposite should happen: A clear statement that deploying sub-standard crypto technologies isn't acceptable and whoever does it has to expect breakage in the future. TLS suffered a lot in the past from misguided attempts to provide backwards compatiblity to weak algorithms. Most of the fancy named vulns in the past years can somehow be traced back to this problem. PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related vuln that could've been prevented by using RSA-PSS was found 2 months ago [1]. The last one in a major implementation (BERserk) was in 2014. tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable. Let's not repeat the mistakes from the past. [1] https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/ -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42
pgpFny99O0zsR.pgp
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
