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

2017-12-15 Thread Martin Rex
Tim Hollebeek wrote: > 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

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

2017-12-15 Thread Martin Rex
Ilari Liusvaara wrote: > On Fri, Dec 15, 2017 at 07:33:44PM +, Tim Hollebeek wrote: >> >> 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

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

2017-12-15 Thread Nikos Mavrogiannopoulos
On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacCárthaigh wrote: > > > But what would that look like? What would we do now, in advance, to > > make it easy to turn off AES? For example. > > I think this is the

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

2017-12-15 Thread Ilari Liusvaara
On Thu, Dec 14, 2017 at 05:05:37PM -0800, Colm MacCárthaigh wrote: > But I do think the question > is worth having an answer for. I think we *do* need to prepare for turning > off AES, there's always a chance we might have to. Even nastier dependency: SHA-2. If that breaks, currently both TLS

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

2017-12-15 Thread Andrei Popov
Here's an attempt to define a SHA-2 alternative: https://tools.ietf.org/html/draft-wconner-blake2sigs-01 Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, December 15, 2017 6:31 AM To: Colm MacCárthaigh

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

2017-12-15 Thread Kathleen Moriarty
On Fri, Dec 15, 2017 at 9:19 AM, Nikos Mavrogiannopoulos wrote: > On Fri, Dec 15, 2017 at 2:01 AM, Hanno Böck wrote: >> >> On Thu, 14 Dec 2017 16:45:57 -0800 >> Colm MacCárthaigh wrote: >> >> > But what would that look like? What would we do

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

2017-12-15 Thread Ilari Liusvaara
On Thu, Dec 14, 2017 at 02:58:59PM -0800, Watson Ladd wrote: > Let's not forget defense 0: migrating away from broken algorithms > (which means turning them off). The fact that we didn't switch MTI > away from RSA encryption in TLS 1.1 after these attacks were > disclosed, or even in TLS 1.2,

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 02:57:33PM +, Andrei Popov wrote: > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara > > Even nastier dependency: SHA-2. If that breaks, currently both TLS > > 1.2 and 1.3 break. There are no alternatives defined. > > Here's an attempt to define a

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

2017-12-15 Thread Eric Rescorla
On Fri, Dec 15, 2017 at 10:14 AM, Ilari Liusvaara wrote: > On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote: > > I'm not quite following how this helps. It's true that if SHA-256 is > > broken, we're in serious trouble, but that's largely because of the

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 10:15:23AM -0800, Eric Rescorla wrote: > On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote: > > > We can force a rotate of all certs in 90 days, and I don't think most > > people will notice. > > > > Unfortunately, there are plenty of longterm

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 11:47:54AM -0500, Kathleen Moriarty wrote: > > Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS > 1.2 and prior? I haven't noticed any discussion on that previously. Is > it just the code base and not those using it being unwilling to > upgrade

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

2017-12-15 Thread Andrei Popov
Correct. -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Friday, December 15, 2017 9:46 AM To: Andrei Popov Cc: Colm MacCárthaigh ; tls@ietf.org Subject: Re: [TLS] A closer look at ROBOT, BB

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

2017-12-15 Thread Eric Rescorla
I'm not quite following how this helps. It's true that if SHA-256 is broken, we're in serious trouble, but that's largely because of the fact that that's what people's certificates have, so clients really can't refuse to support SHA-256 certificates. So, how does adding new algorithms help?

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 10:07:16AM -0800, Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is > broken, we're in serious trouble, but that's largely because of the fact > that that's what people's certificates have, so clients really can't refuse > to

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

2017-12-15 Thread Tim Hollebeek
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

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

2017-12-15 Thread Andrei Popov
> 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

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

2017-12-15 Thread Tim Hollebeek
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

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 07:25:20PM +, Andrei Popov wrote: > > 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

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

2017-12-15 Thread Andrei Popov
It's true, the migration will be slow, but IMHO it still makes sense to define and implement an alternative hash. -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, December 15, 2017 10:34 AM To: Eric Rescorla Cc:

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 06:41:06PM +, 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

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 07:14:00PM +, Tim Hollebeek wrote: > 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. Well, I would think that having ready to go

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

2017-12-15 Thread Ilari Liusvaara
On Fri, Dec 15, 2017 at 07:33:44PM +, Tim Hollebeek wrote: > > 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

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

2017-12-15 Thread Hanno Böck
On Fri, 15 Dec 2017 11:47:54 -0500 Kathleen Moriarty wrote: > Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS > 1.2 and prior? I haven't noticed any discussion on that previously. Is > it just the code base and not those using it being

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

2017-12-15 Thread Watson Ladd
We can force a rotate of all certs in 90 days, and I don't think most people will notice. On Fri, Dec 15, 2017 at 10:07 AM, Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is broken, > we're in serious trouble, but that's largely because of

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

2017-12-15 Thread Eric Rescorla
On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd wrote: > We can force a rotate of all certs in 90 days, and I don't think most > people will notice. > Unfortunately, there are plenty of longterm certificates with lifetimes >> 90 days. -Ekr > > On Fri, Dec 15, 2017 at