Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Tim Hollebeek <[e-mail]>]

Because it's easier for the client to decide what the client understands
than it is for the server to decide what the client understands.  Less
complexity = less failures.  

Note that this is how XP was handled for code signing.  The Authenticode
spec actually made it so if you did things in the right order, XP would only
see the SHA-1 signature, while more recent operating systems would see both
the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the
SHA-2 signature.  This allowed doubly-signed binaries that worked both on XP
and non-XP systems.  Unfortunately the technical steps to do so weren't
widely publicized, but I know some companies took advantage of it.

However, servers are easier to upgrade than clients, which is why you see
some of the server side support you mention.  I know CloudFlare in
particular helped a lot of people cope with communicating with clients who
had different certificate capabilities.  It isn't a bad thing that both
approaches exist.

-Tim

> -----Original Message-----
> From: Andrei Popov [mailto:[e-mail]]
> Sent: Friday, December 15, 2017 12:25 PM
> To: Tim Hollebeek <[e-mail]>; Ilari Liusvaara
> <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
> general, and what we can do in TLS
> 
> > Ideally, you'd want certificates to be able to have two signatures
> > during the transition period, in order to support clients who have
> > transitioned and those who have not.
> 
> > Hosting multiple certificates and switching based on the client is
> > feasible, but requires some technical wizardry and isn't possible in all
> situations.
> 
> For my understanding, why is the former (double-signed certs, where either
> signature is trusted) better than the latter (multiple certs with
different
> algorithms)?
> The latter is currently supported by some TLS servers.
> 
> Cheers,
> 
> Andrei