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

[Tim Hollebeek <[e-mail]>]

So, this has been discussed extensively at the CA/Browser forum, for obvious
reasons.

In my mind, it is not so important to identify and define and implement an
alternative hash.

What *is* important is that the protocol and associated software is able to
support a smooth transition period where people are moving from one
algorithm to another.

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.  Unfortunately RFC 5280 is deficient in that regard.
Hosting multiple certificates and switching based on the client is feasible,
but requires some technical wizardry and isn't possible in all situations.

A lot of these transitions are painful because with the way things currently
work, algorithms have to reach near ubiquity before the transition can begin
(the popularity of Windows XP was a huge problem).

The transition will happen at different rates for various industries and use
cases that have different security requirements, so everyone needs to be
able to move at a pace that makes sense for their needs.  It needs to be
carefully coordinated, and yes, transitions will take years.  The current
maximum certificate lifetime is a compromise between the speed at which
changes can be made, and the pain imposed by replacement, which largely
still isn't automated.  I know people are working to improve that, but we
are where we are.

-Tim

> -----Original Message-----
> From: TLS [mailto:[e-mail]] On Behalf Of Ilari Liusvaara
> Sent: Friday, December 15, 2017 11:50 AM
> To: Andrei Popov <[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
> 
> On Fri, Dec 15, 2017 at 06:41:06PM +0000, Andrei Popov wrote:
> > It's true, the migration will be slow, but IMHO it still makes sense
> > to define and implement an alternative hash.
> 
> Agreed. However, on certificates front, we need a method to perform
> backward-compatible algorithm transition. Because non-backward-
> compatible ones are just too hard. As we have seen _twice_.
> 
> On TLS handshake hashes, the transitions are already backward- compatible.
> But that does not mean the transition will be easy.
> 
> 
> 
> 
> -Ilari
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls