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

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

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

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

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 
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=04%7C01%7CAndrei.Popov%40microsoft.com%7C22779f9a38834781928208d543c87f97%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636489450805010503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=yVHsF021AGtXGR0DDpm2mV07gsCThPjk%2BGsDm8R4UyE%3D=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

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

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

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

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

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

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

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 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=04%7C01%7CAndrei.P
> opov%40microsoft.com%7C30de6e3a48024110441608d543e3c8b7%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C636489567969040822%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&
> sdata=f72MvX0ydw5WvjkvngbY39sai8v9oOc5ZUYZOQI3XmI%3D=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

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

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

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

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

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

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

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: 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=04%7C01%7CAndrei.Popov%40microsoft.com%7C248257e4202549b54e9208d543ea7ff7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636489596817634560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=viW%2F6xW3bJoG6SlxgENwp%2BFH8%2Bqnb%2BFynkE4Yxfq%2Bjc%3D=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

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

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

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

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

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

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