Re: [TLS] Empty extensions don't go last

[Andrei Popov]

Yes, we found this a while ago as well, and had to move extensions around.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Wan-Teh Chang
Sent: Thursday, March 24, 2016 12:04 AM
To: Martin Thomson 
Cc: tls@ietf.org
Subject: Re: [TLS] Empty extensions don't go last

On Wed, Mar 23, 2016 at 10:30 PM, Martin Thomson  
wrote:
> (This is probably already known to a bunch of people, but it's 
> probably a good idea to put out there.)
>
> When deploying EMS, we recently discovered, with the help of our 
> friends at Google (who discovered this long before that) a quirk in 
> some implementations.
>
> Short story:  Don't place an empty extension at the end of your 
> ClientHello.  You will find that a small number of servers choke.

This interop problem surfaces when we added to Chrome the 
signed_certificate_timestamp extension for Certificate Transparency (RFC 6962):

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs.chromium.org%2fp%2fchromium%2fissues%2fdetail%3fid%3d353009%23c4=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1=YUuVpA6X5QhQZGOS%2bHbs30ooKE%2bW9U0W4cr6tG%2bbKEo%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs.chromium.org%2fp%2fchromium%2fissues%2fdetail%3fid%3d363583%23c13=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1=ddplXkVwDs4SMUaRpcdc0TY%2fipYDB8rYwWeTAsvc0Kc%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcodereview.chromium.org%2f240633006=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1=5bQKBz4Y8R%2fmVKHLzpbnVBOj428W0T3regpgaBkl0MY%3d

The change that David Benjamin made to
ssl3_CalculatePaddingExtensionLength() in his patch probably should also be 
considered if the padding extension (RFC 7685) is placed at the end:

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcodereview.chromium.org%2f240633006%2fdiff%2f110001%2fnet%2fthird_party%2fnss%2fssl%2fssl3ext.c=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1=jH5GKij0h%2boPSy4BaRvePsiN7zx2gycuSYraYDiTS4E%3d

Wan-Teh Chang

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1=gdOOA8X6H1QMVzL3JLh%2b%2f0YHesyIQKZjjhimdP3%2fYn0%3d

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

[Peter Gutmann]

Hubert Kario  writes:

>In my experience, many (12%) servers simply ignore the list of curves
>advertised by client and use the P-256 curve always.
>
>Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 is
>not advertised.

When I checked, which is a year or two back now, I found similar problems (I
didn't get hard figures but I had the feeling it was a lot higher than 12%,
but then I wasn't conducting a rigorous survey).  Conversely, I found that if
you just ploughed ahead with P-256, things usually worked.  This is what
motivated the use of P-256 in -LTS, it's the de facto standard curve.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

[Fedor Brunner]

Timothy Jackson:
> I’ve noted that many (most?) TLS implementations choose their ECDHE curves 
> seemingly without regard to the cipher suite strength. Thus, they'll select 
> an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then 
> generate an ECDHE key on the P256 curve. This seems odd to me, since the P256 
> curve obviously has a lower security strength than AES256. This seems 
> important issue to resolve because most products (and even TLS libraries) do 
> not allow the administrator to configure the available ECDHE curves, only the 
> cipher suites. Thus, ECDHE may be invisibly undermining the security of your 
> TLS connection.
> 
> Is this an intentional choice by this group for some reason that I haven’t 
> realized yet?
> 
> How would this group feel about a proposal to address this by specifying in 
> the 1.3 specification that implementations must ensure that the strength of 
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? 
> Perhaps an equivalency rule for the MAC might also be in order? Apologies if 
> this is already resolved somewhere in the draft RFC. I looked but didn’t find 
> it.
> 
> For what it’s worth, I’ve noticed OpenSSL and other implementations trying to 
> address this by creating a “Suite B Mode”, but that seems to address a 
> specific case but leave the generic case unresolved.
> 
> Cheers,
> 
> Tim
> 
> 
There are good reasons to combine AES256 with ECDHE on the P256 curve.

Please read
https://blog.cr.yp.to/20151120-batchattacks.html

"Bottom line: 128-bit AES keys are not comparable in security to 255-bit
elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe?
Unclear."

There is also the paper "Understanding brute force" from Daniel J.
Bernstein.
https://cr.yp.to/papers.html#bruteforce
> 
> ___
> 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