Re: [TLS] Fresh results

[Hubert Kario <[e-mail]>]

On Friday 04 December 2015 00:52:08 Hanno Böck wrote:
> On Thu, 3 Dec 2015 18:45:14 -0500
> 
> Watson Ladd <[e-mail]> wrote:
> > On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck <[e-mail]> 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