On Friday 04 December 2015 00:52:08 Hanno Böck wrote: > On Thu, 3 Dec 2015 18:45:14 -0500 > > Watson Ladd <watsonbl...@gmail.com> wrote: > > On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck <ha...@hboeck.de> wrote: > > > So as long as you make sure you implement all the proper > > > countermeasures against that you should be fine. (Granted: This is > > > tricky, as has been shown by previous results, even the OpenSSL > > > implementation was lacking proper countermeasures not that long > > > ago, > > > but it's not impossible) > > > > Can you describe the complete set of required countermeasures, and > > prove they work comprehensively? What if the code is running on > > shared hosting, where much better timing attacks are possible? > > What's shocking is that this has been going on for well over a > > decade: the right solution is to use robust key exchanges, and yet > > despite knowing that this is possible, we've decided to throw patch > > onto patch on top of a fundamentally broken idea. There is no fix > > for PKCS 1.5 encryption, just dirty hacks rooted in accidents of > > TLS. > > No disagreement here. > > The thing is, we have a bunch of difficult options to choose from: > > * Fully deprecate RSA key exchange. > The compatibility costs of this one are high. They are even higher > considering the fact that chrome wants to deprecate dhe and use rsa as > their fallback for hosts not doing ecdhe. ecdhe implementations > weren't widespred until quite recently. A lot of patent foo has e.g. > stopped some linux distros from shipping it.
Then maybe Chrome should reconsider. I think we're overstating the compatibility costs. very few widely deployed implementations (with the exception of the long deprecated Windows XP) lack support for DHE_RSA *and* ECDHE_RSA at the same time -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
