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 wrong way to look at it. > > From what I'm aware nobody is really concerned about the security of > AES. I don't think that there's any need to prepare for turning off AES. > > The problem with PKCS #1 v1.5 is that it survived so long *after* its > was known that it was bad. I really recommend everyone who wants to > know how protocols go bad to read up on the Bleichenbacher > countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last > one. The chapter in 1.2 is a nightmare and I seriously fail to > understand how anyone could have seen that and think it's a good idea > to do that in order to stay compatible with a standard that was already > deprecated at that point. > > We know that when this group decided to deprecate both PKCS #1 1.5 and > RSA encryption that there were people trying to lobby against that. I'm > glad that this wasn't successful. > RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact the security of TLS 1.3 is heavily tied to these primitives if servers support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice if we can only deprecate RSA PKCS#1 1.5 at some point. regards, Nikos [0]. https://github.com/tlswg/tls13-spec/pull/1123 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 1.2 and 1.3 break. There are no alternatives defined. Yes, sure SHA-2 has taken a lot of cryptoanalysis without serious trouble (I think one reason for starting SHA-3 process was preceived weakness in SHA-2, that later turned out not to be the case). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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, means that we've got a very long time > before some sites can turn off these algorithms. Given that some > places can't turn off SSL v3, it's not clear we can ever turn off a > widely implemented protocol. I think the main problem in way of just deleting static RSA code is those "visibility" folks. Because vast majority of clients that are not utter garbage for other reasons support PFS with decent key sizes. (And then there are folks that interpret MTI in insane ways). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 Cc: tls@ietf.org Subject: 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 1.2 and 1.3 break. There are no alternatives defined. Yes, sure SHA-2 has taken a lot of cryptoanalysis without serious trouble (I think one reason for starting SHA-3 process was preceived weakness in SHA-2, that later turned out not to be the case). -Ilari ___ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C22779f9a38834781928208d543c87f97%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636489450805010503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=yVHsF021AGtXGR0DDpm2mV07gsCThPjk%2BGsDm8R4UyE%3D&reserved=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 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 the security of >> AES. I don't think that there's any need to prepare for turning off AES. >> >> The problem with PKCS #1 v1.5 is that it survived so long *after* its >> was known that it was bad. I really recommend everyone who wants to >> know how protocols go bad to read up on the Bleichenbacher >> countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last >> one. The chapter in 1.2 is a nightmare and I seriously fail to >> understand how anyone could have seen that and think it's a good idea >> to do that in order to stay compatible with a standard that was already >> deprecated at that point. >> >> We know that when this group decided to deprecate both PKCS #1 1.5 and >> RSA encryption that there were people trying to lobby against that. I'm >> glad that this wasn't successful. > > > RSA PKCS #1 1.5 decryption and signatures are far from deprecated. In fact > the security of TLS 1.3 is heavily tied to these primitives if servers > support TLS 1.2 and RSA (see [0]) alongside TLS 1.3. It would be very nice > if we can only deprecate RSA PKCS#1 1.5 at some point. 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 supporting libraries? >From RFC8017: To avoid implementation weaknesses related to the way errors are handled within the decoding operation (see [BLEICHENBACHER] and [MANGER]), the encoding and decoding operations for RSAES-OAEP and RSAES-PKCS1-v1_5 are embedded in the specifications of the respective encryption schemes rather than defined in separate specifications. Both encryption schemes are compatible with the corresponding schemes in PKCS #1 v2.1. And, yes, I know deprecation is very hard, but if there's been no effort, it should be considered as TLS 1.2 isn't going away anytime soon. Thanks, Kathleen > > regards, > Nikos > > [0]. https://github.com/tlswg/tls13-spec/pull/1123 > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 unwilling to > upgrade supporting libraries? It depends... particularly if we talk about encryption or signatures. With Bleichenbacher attacks there are plenty of cross-protocol attack possibilities, this was one of the papers at the TRON workshop: https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf While I believe we certainly can't get rid of PKCS #1 1.5 signatures any time soon, I think we can get rid of PKCS #1 1.5 encryption (at least on the server side for HTTPS). The number of legit connections is really low. If you run servers please check if you can do that. (I'm also considering writing an RSA-kex-diediedie RFC when I find time for it.) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 supporting libraries?
>
> >From RFC8017:
>
>To avoid implementation weaknesses related to the way errors are
>handled within the decoding operation (see [BLEICHENBACHER] and
>[MANGER]), the encoding and decoding operations for RSAES-OAEP and
>RSAES-PKCS1-v1_5 are embedded in the specifications of the respective
>encryption schemes rather than defined in separate specifications.
>Both encryption schemes are compatible with the corresponding schemes
>in PKCS #1 v2.1.
>
> And, yes, I know deprecation is very hard, but if there's been no
> effort, it should be considered as TLS 1.2 isn't going away anytime
> soon.
The problem is that handling a decryption fault in TLS 1.2 and prior is
hard. The TLS 1.2 RFC already discusses how to do that.
Basically, if decryption fails, you need to carry on as nothing had
happened, but then cause Finished MAC check to fail. In _constant_
time. Which is not easy, and even if your code looks constant time,
compiler "optimizations" can really ruin your day.
I think there should be a draft which formally deprecates RSA,
recommends the support to be removed (at least from server side)
and updates TLS 1.2 to change the MTI ciphersuite. Of course,
certain ("visibility") folks would scream about that.
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/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 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 SHA-2 alternative: > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 Also would need TLS ciphersuite codepoints with alternative handshake hash algorithms. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 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 SHA-2 alternative: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools > .ietf.org%2Fhtml%2Fdraft-wconner-blake2sigs-01&data=04%7C01%7CAndrei.P > opov%40microsoft.com%7C30de6e3a48024110441608d543e3c8b7%7C72f988bf86f1 > 41af91ab2d7cd011db47%7C1%7C0%7C636489567969040822%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1& > sdata=f72MvX0ydw5WvjkvngbY39sai8v9oOc5ZUYZOQI3XmI%3D&reserved=0 Also would need TLS ciphersuite codepoints with alternative handshake hash algorithms. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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? (That's why I would argue that the existing SHA-384 support doesn't help). -Ekr On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara wrote: > 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 SHA-2 alternative: > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 > > Also would need TLS ciphersuite codepoints with alternative handshake > hash algorithms. > > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 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? (That's why I > would argue that the existing SHA-384 support doesn't help). > > -Ekr > > > On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara > wrote: >> >> 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 SHA-2 alternative: >> > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 >> >> Also would need TLS ciphersuite codepoints with alternative handshake >> hash algorithms. >> >> >> -Ilari >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 support SHA-256 certificates. So, how does adding new algorithms help? > (That's why I would argue that the existing SHA-384 support doesn't help). TLS handshake assumes the hash function is strongly collision- resistant. So if SHA-256/SHA-384 breaks, the handshake hash function needs to be replaced. This is separate from certificate signatures. Transitioning this would be much more nasty than TLS handshake hash, because there is no backward-compatible way of changing the hash. This is one major reason why SHA-1 transition took over 10 years (oh, then there is the "fun" post-quantum transition possibly coming up). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 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 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? (That's > why I > > would argue that the existing SHA-384 support doesn't help). > > > > -Ekr > > > > > > On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > >> > >> 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 SHA-2 alternative: > >> > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 > >> > >> Also would need TLS ciphersuite codepoints with alternative handshake > >> hash algorithms. > >> > >> > >> -Ilari > >> > >> ___ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 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? > > (That's why I would argue that the existing SHA-384 support doesn't > help). > > TLS handshake assumes the hash function is strongly collision- > resistant. So if SHA-256/SHA-384 breaks, the handshake hash function > needs to be replaced. > Yes. In 1.3, you would define new cipher suites with the new hash. But of course you then have to worry about downgrade if clients jointly support the weakest hash and it's weak enough. -Ekr This is separate from certificate signatures. Transitioning this would > be much more nasty than TLS handshake hash, because there is no > backward-compatible way of changing the hash. This is one major reason > why SHA-1 transition took over 10 years (oh, then there is the "fun" > post-quantum transition possibly coming up). > > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 certificates with lifetimes >> > 90 days. Yes, currently the lifetime limit for public certificates is 39 months, and will be reduced to 825 days (~27 months) effective March 2018. Then there is backdating to consider. It was seen in both MD5 and SHA-1 deprecations. So maximum certificate lifetime sets limit on how fast features can be flushed out. And then there would be enormous amounts of endpoints not supporting anything better. Those would have to be upgraded. All in all, a real mess. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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: tls@ietf.org 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 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 certificates with > lifetimes >> > 90 days. Yes, currently the lifetime limit for public certificates is 39 months, and will be reduced to 825 days (~27 months) effective March 2018. Then there is backdating to consider. It was seen in both MD5 and SHA-1 deprecations. So maximum certificate lifetime sets limit on how fast features can be flushed out. And then there would be enormous amounts of endpoints not supporting anything better. Those would have to be upgraded. All in all, a real mess. -Ilari ___ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C248257e4202549b54e9208d543ea7ff7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636489596817634560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=viW%2F6xW3bJoG6SlxgENwp%2BFH8%2Bqnb%2BFynkE4Yxfq%2Bjc%3D&reserved=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 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:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Friday, December 15, 2017 11:50 AM > To: Andrei Popov > Cc: tls@ietf.org > 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 +, 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 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:andrei.po...@microsoft.com] > Sent: Friday, December 15, 2017 12:25 PM > To: Tim Hollebeek ; Ilari Liusvaara > > Cc: tls@ietf.org > 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 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 backup would cut fair amount of time from transitions. It should be noted that the two transitions we have seen had backup algorithm already (SHA-1 in case of MD5 and SHA-2 in case of SHA-1). > 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. Yes, that is what I was referring with "backward-compatible algorithm transition". > 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. Yes, there are enormous amount of stacks that have problems with multiple certificate chains. Ranging from OCSP stapling not working properly (Nginx+openSSL) to dual-cert not working at all (too many to list). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 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. Because the latter is only supported by some TLS servers. And even if the TLS server nominally supports multiple certificates, there may be other issues. E.g., OCSP stapling does not work correctly with multiple certificates. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/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 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 different certificate capabilities. It isn't a bad thing that both > approaches exist. Also, it should be noted that the past two migrations needed to be compatible with TLS 1.0 and 1.1, which have much less advanced signature negotiation than TLS 1.2 (and 1.3). However, there are enormous amount of very badly configured servers out there, so it is doubtful how quickly things change. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 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. Now that sounds weird. If I look at the code signatures on my Windows 7 machine, e.g. C:\windows\ccm\CcmExec.exe it carries one single digital signature & timestamp _from_Microsoft_ created 01-November-2017 and both with sha1RSA. So it seems some vendors haven't really started migrating away from SHA-1. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 people cope with communicating with clients who >> had different certificate capabilities. It isn't a bad thing that both >> approaches exist. > > Also, it should be noted that the past two migrations needed to be > compatible with TLS 1.0 and 1.1, which have much less advanced > signature negotiation than TLS 1.2 (and 1.3). There is an awfully large installed base of borked TLSv1.2 servers. If those servers are equipped with a sha256WithRsaEncryption server cert, the handshake results are: - TLSv1.0 for SSLv3 ClientHello w/ client_version = (3,1) - TLSv1.1 for SSLv3 ClientHello w/ client_version = (3,2) - TLSv1.1 for SSL VERSION 2 CLIENT-HELLO offering (3,3) - chokes and drops network connection for SSLv3 ClientHello w/ client_version = (3,3) i.e. there exists a serious interop problem for TLSv1.2 with such servers, but there is no problem interoperating with TLSv1.0 or TLSv1.1 -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
