On Mon, Feb 06, 2017 at 01:12:05AM +0100, Nikos Mavrogiannopoulos wrote: > > The issue is that we cannot tell for sure. Any proof of security > assumes that the keys are restricted to a single scheme. So I think we > got into a trap where we intended to increase security, while in fact > reduced the protocol's security, by ending-up adding RSA-PSS in a way > that can share keys with PKCS#1 1.5. I think that we should treat RSA- > PSS as the mean to increase security rather than the end-goal.
Looking at the signature constructions, I would say it is _extremely_ unlinkely that cross-protocol attacks are possible. And this is with extremely loose criteria and extremely loose attacker resource budget. > Even if the approach of separating keys would mean that RSA-PSS will > not be deployed immediately, it will allow implementors to provide > well-behaved clients that will refuse to mix marked as RSA-PSS keys > with the legacy ones. On the current protocol description it is > impossible for an implementor to do that. The reason is that if one > does that, his software will not be functional, will fail to connect to > several web servers, and thus will have to compromise (functionality > always wins over security). > > > > [2] Some commercial CAs (don't have list) and Let's Encrypt (signed > > with RSA[3] and even then most ACME software can't handle those).. > > TLS 1.3 requiring a different key type, will provide an incentive for > them to update. More like roadblock to upgrade to TLS 1.3. Getting CA support for RSA-PSS keys would be SLOW to say the least. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
