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

On Mon, Jan 8, 2018 at 6:29 AM, Hubert Kario wrote: > > except that what we call "sufficiently hard plaintext recovery" is over > triple > of the security margin you're proposing as a workaround here > > 2^40 is doable on a smartphone, now > 2^120 is not doable on a

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

On Thursday, 4 January 2018 20:01:03 CET Colm MacCárthaigh wrote: > On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario wrote: > > > No, I strongly disagree here. Firstly, frustrating attackers is a good > > > definition of what the goal of security is. Some times increasing costs > >

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

On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario wrote: > > No, I strongly disagree here. Firstly, frustrating attackers is a good > > definition of what the goal of security is. Some times increasing costs > for > > attackers does come at the cost of making things harder to

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

- Original Message - > From: "Colm MacCárthaigh" > To: "Hubert Kario" > Cc: tls@ietf.org > Sent: Wednesday, January 3, 2018 6:23:03 PM > Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in > general, and what we can do in TLS

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

On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario wrote: > > > *Second: hide all alerts in suspicious error cases* > > Next, when the handshake does fail, we do two non-standard things. The > > first is that we don't return an alert message, we just close the > > connection. > > > >

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

On Friday, 15 December 2017 19:07:16 CET 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 support

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

On Thursday, 14 December 2017 23:20:54 CET Colm MacCárthaigh wrote: > Based on our experiences with all of this over the last few weeks, I'd like > to summarize and throw out a few suggestions for making TLS stacks more > defensive and robust against problems of this class. One or two may be even

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

On Wed, Dec 20, 2017 at 03:37:46PM +, Peter Gutmann wrote: > The reason I ask is a combination of two things, firstly I've done timing > measurements on my own code to try and detect differences in behaviour and > couldn't find anything among the general noise of code execution, and secondly

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

Colm MacCárthaigh writes: >since it's important not to leak timing, we use a special >"constant_time_copy_or_dont" routine to do the over-write: > >https://github.com/awslabs/s2n/blob/master/utils/s2n_safety.c#L70 Has anyone actually been able to measure the impact of issues

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

On Sat, Dec 16, 2017 at 12:30:06AM +0100, Martin Rex wrote: > 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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

> On 15 Dec 2017, at 3:05, Colm MacCárthaigh wrote: > > > > On Thu, Dec 14, 2017 at 5:01 PM, Hanno Böck > wrote: > On Thu, 14 Dec 2017 16:45:57 -0800 > Colm MacCárthaigh > wrote: > >

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

On Thu, Dec 14, 2017 at 5:01 PM, 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

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 wrong way to look at it. From what I'm aware nobody is really concerned about

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

Bringing this back to TLS-WG territory. Deprecating algorithms is hard work and can take a long time. Having been through MD5, RC4, 3DES, SHA1 deprecations and CBC de-prioritisations, it was a lot of work and network effects work against rapid changes. What else could we be doing here? One option

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

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, means that we've got a very long time before some sites can turn off