Subject: [TLS] This working group has failed

From: Watson Ladd <[email-masked]>
Date: Fri, 15 Nov 2013 20:53:32 -0800

In the past decade there have been many attacks against TLS.
With the exception of CRIME, not one of them relied on any results
that were not known
at the time the TLS 1.0 standard was being written. (See the citations
for the RC4 paper to see this, or the infamous Rogaway email about AtE
vs EtA). Every time this standards group has had a choice to make
regarding cryptography, they have made the wrong one. Even AES-GCM got
screwed up: nonces should be counters, but all implementations make
them random, introducing an artificial birthday bound issue due to
truncation in the standard.

TLS is solving the deadest of dead problems in cryptography: using the
PKI to establish a secure channel between two endpoints. Diffie and
Hellman solved this in their paper. Were TLS to be submitted by an
undergraduate as a solution to this problem it would earn an F.
Implementers such as AGL are bypassing the WG, choosing to emit I-Ds
and implementing and deploying because there is little to be gained
from WG discussions. This is not necessarily a bad thing, but it does
raise a question of whether what is good for Google is good for the
Web as a whole.

What problems would a hypothetical competition solve that TLS 1.2
hasn't already? Let's deal with real problems: TLS 1.2 is not getting
deployed, RC4 is still out there, the handshake protocol takes too
many round trips and is very hard to implement in an interoperable way
due to options, all the implementations with modern cryptographic
support have sucky APIs that make it impossible for ordinary
developers to use correctly, etc. All of this I have said before as
main priorities, but they are the biggest issues affecting us today. I
propose that a chair (do we have one?) convene a meeting via IRC or in
person at some convenient event to determine what problems should be
priorities, and then we will address them.

There are a few good points: I am glad to see that major vendors are
represented on this list, and are generally willing to work together
to insure interoperability and remove obstacles to improving internet
security. I am also glad to see that we are acutely aware of the
issues currently threatening the lives and property of internet users.

Sincerely,
Watson

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 16 Nov 2013 11:14:14 +0100

Hi Watson,

I understand your frustration and I wanted to pick up one point that you 
raised, namely why does it take so long to get TLS versions and 
extensions deployed.

I had recently a chat with a friend, Thomas Schreck who works for the 
Siemens CERT, and in the discussion about TLS I told him that he needs 
to deploy TLS 1.2 inside the company. He responded to me that support 
for TLS 1.2 has only been added to OpenSSL last year (which seems to be 
correct when I check the change logs where the initial support has been 
added with version 1.0.1).

The TLS 1.2 spec was, however, finished in 2008.

Having the code in the library is only the first step since then all the 
applications that use the library also need to be updated (re-compliled 
at least and shipped). Hard to say how long that takes and depends on 
the application and the company.

To be positive and constructive in the discussion I wonder what could be 
done to improve the situation.

Does the OpenSSL and the GnuTLS projects (and other projects) need more 
contributors?

Is there more awareness building needed to get companies to understand 
what the different libraries provide and why they should use a 
particular version?

Where does the delay come from?

Ciao
Hannes

Am 16.11.13 05:53, schrieb Watson Ladd:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Taylor Hornby <[email-masked]>
Date: Sat, 16 Nov 2013 11:09:58 -0700

> Where does the delay come from?

Firefox is one of the last browsers to get TLS 1.1 and TLS 1.2 support.
It's still not enabled by default in the stable release. Looking at
their development history is probably the best place to start.

TLS 1.1:

https://bugzilla.mozilla.org/show_bug.cgi?id=565047
https://bugzilla.mozilla.org/show_bug.cgi?id=733647

TLS 1.2:

https://bugzilla.mozilla.org/show_bug.cgi?id=480514
https://bugzilla.mozilla.org/show_bug.cgi?id=861266

Most of the delay seems to be in Bug 565047. TLS 1.1 was standardized in
2006, but the *ticket* to implement TLS 1.1 was created FOUR YEARS
later. Then, once it was, it took TWO YEARS to implement.

Non-compliant servers are wasting a ton of time in QA, too:

https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48
https://bugzilla.mozilla.org/show_bug.cgi?id=839310

Why doesn't TLS's fallback mechanism work?

So, it seems to me that:

1. The most significant delay is between when the standard is released
and when vendors realize they have to implement it. Until there's a
problem with the old version, they're hardly thinking about it.

2. Once they do realize it's necessary, it takes a long time to implement.

-- 
Taylor Hornby

---

From: SM <[email-masked]>
Date: Sat, 16 Nov 2013 07:25:22 -0800

Hi Watson,
>developers to use correctly, etc. All of this I have said before as

It is well-known that TLS 1.2 was not getting deployed.  There are 
two libraries which are widely used.  If one of them does not support 
TLS 1.x deployment will be slow.  The lack of deployment affects 
several other IETF protocols.

A RFC is not successful if it is not implemented.  RFC 6982 discusses 
about running code.

Regards,
-sm

---

From: Ralph Holz <[email-masked]>
Date: Sat, 16 Nov 2013 20:36:58 +0100

Hi,

> It is well-known that TLS 1.2 was not getting deployed.  There are two
> libraries which are widely used.  If one of them does not support TLS

FWIW: When we recently scanned IPv4 with a standard openssl, we found
about 33M hosts that supported SSL3 or higher, and 14% of them accepted
our offer of TLSv1.2.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 17 Nov 2013 11:30:39 +0100

Hi Taylor,

Would be interesting to hear from someone working for Mozilla (like Ekr, 
our TLS WG chair) why things are progressing so slowly and what exactly 
their problem is.

Ciao
Hannes

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Nov 2013 11:12:55 +0000

On Nov 17, 2013, at 12:30 PM, Hannes Tschofenig <[email-masked]> wrote:

> Hi Taylor,
> 
> Would be interesting to hear from someone working for Mozilla (like Ekr, our TLS WG chair) why things are progressing so slowly and what exactly their problem is.
> 

Hi Hannes

We have heard before from people at Google and at Microsoft. Google only added TLS 1.2 very recently, and Microsoft added it very early, but disabled it by default for a long time.

There were issues with failures of connections attempts using TLS 1.2.  There have been issues with 1.1, but 1.2 produced much more of them.

 1. TLS 1.2 is the first version to require support of extensions. Some servers broke when extensions existed.
 2. Some servers broke on unrecognized extensions.
 3. Some server break on missing extensions - certain servers will not accept a TLS 1.2 ClientHello without the SignatureAlgorithm extension

Combining 1 & 3, you can't win. Some servers just won't work.

I don't know what changed. Perhaps the percentage of servers that are broken like that has diminished. But not it looks like the browser vendors have deemed it as sufficiently low to allow them to make this on by default.

Yoav

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 17 Nov 2013 12:53:12 +0100

Hi Yoav,

thanks for the response.

I interested in those views only to collect some data points for 
improving the rate of adoption in the future. You might think I am 
strange but I think we should learn from those mistakes and avoid them 
in the future.

 From what you write below I am wondering what TLS libraries these 
problematic servers have been using? Do we know more about that?

Ciao
Hannes

Am 17.11.13 12:12, schrieb Yoav Nir:
>> Would be interesting to hear from someone working for Mozilla (like
>> Ekr, our TLS WG chair) why things are progressing so slowly and
>> what exactly their problem is.
>>
>
> Hi Hannes
>
> We have heard before from people at Google and at Microsoft. Google
> only added TLS 1.2 very recently, and Microsoft added it very early,
> but disabled it by default for a long time.
>
> There were issues with failures of connections attempts using TLS
> 1.2.  There have been issues with 1.1, but 1.2 produced much more of
> them.
>
> 1. TLS 1.2 is the first version to require support of extensions.
> Some servers broke when extensions existed. 2. Some servers broke on
> unrecognized extensions. 3. Some server break on missing extensions -
> certain servers will not accept a TLS 1.2 ClientHello without the
> SignatureAlgorithm extension
>
> I don't know what changed. Perhaps the percentage of servers that are
> broken like that has diminished. But not it looks like the browser
> vendors have deemed it as sufficiently low to allow them to make this
> on by default.
>
> Yoav
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 17 Nov 2013 10:17:01 -0500

> Implementers such as AGL are bypassing the WG, choosing to emit I-Ds and implementing and deploying because there is little
> to be gained from WG discussions. This is not necessarily a bad thing, but it does raise a question of whether what is good for
> Google is good for the Web as a whole.

If, a few years ago, Microsoft did the same thing I have no doubt what the public reaction would be.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 07:24:59 +1100

> 3. Some server break on missing extensions - certain servers will not accept a TLS 1.2 ClientHello without the SignatureAlgorithm extension

It seems like TLS is facing problems similar to those that HTTP is regarding Upgrade. Maybe the takeaway is that one of the more important things to get right is the test suite for extensibility / versioning in any new protocol (alas, too late for TLS and HTTP…).

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Kyle Hamilton <[email-masked]>
Date: Sun, 17 Nov 2013 12:43:22 -0800

If the library were a drop-in replacement that didn't alter binary
compatibility, it would be a simple matter to just drop it in, put a new
config defaults and override file in place, and call it done.

Unfortunately, C is not this easy. The application linking process is
complex (particularly with OpenSSL's FIPScanister), and it's not getting
any easier -- I love how simple it is to drop a new CLR assembly in place
and have the environment simply pick up the changes, but that
configurability comes at the price of having to use the CLR runtime.

Perhaps something that would perform the same function as and
overload/override the platform-native dynlib loading would help, then
integrated into the security libraries that most need it, would help.

I have found myself despising C and C++ and other compiled-to-native
languages as a result of this kind of thing. I am not volunteering to
create such, and frankly I wouldn't even know where to begin -- but
standardizing dynamic library capabilities across most/all OSes would go a
long way toward making security updates and new security capabilities much
easier for administrators to deal with.

-Kyle H
On Nov 16, 2013 2:14 AM, "Hannes Tschofenig" <[email-masked]>
wrote:

> raised, namely why does it take so long to get TLS versions and extensions
> deployed.
>
> Siemens CERT, and in the discussion about TLS I told him that he needs to
> deploy TLS 1.2 inside the company. He responded to me that support for TLS
> 1.2 has only been added to OpenSSL last year (which seems to be correct
> when I check the change logs where the initial support has been added with
> version 1.0.1).
>
> applications that use the library also need to be updated (re-compliled at
> least and shipped). Hard to say how long that takes and depends on the
> application and the company.
>
> what the different libraries provide and why they should use a particular
> version?
>

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sun, 17 Nov 2013 23:44:44 +0200

> On 17.11.2013, at 22.43, Kyle Hamilton <[email-masked]> wrote:
> 
> If the library were a drop-in replacement that didn't alter binary compatibility, it would be a simple matter to just drop it in, put a new config defaults and override file in place, and call it done.
> 
> Unfortunately, C is not this easy.
> 
...
> I have found myself despising C and C++ and other compiled-to-native languages as a result of this kind of thing.
> 

I'm not sure why C is getting the blame here. C++ has had its problems with binary compatibility across compiler versions etc, but C calling conventions are usually very clearly defined. (cdecl/stdcall separation on windows confuses this a bit) Yes, a Windows library doesn't work well in Linux, but neither do CLR binaries, Mono is not a serious option for this kind of stuff.

What is a bigger problem is designing a stable API between major upgrades. This is indeed slightly easier in languages that support overloading methods, like C++ or C#, compared to plain C. However, TLS 1.2 (and based on the discussion TLS 1.3/2.0 as well) are major updates to the protocol, I don't think it is going to be that easy to do a major upgrade without affecting the API, be it CLR or compiled to native. Having a new crossplatform dynamic loader doesn't help much if the API cannot be kept stable, it would only add new restrictions.

The problem you've brought up is certainly valid, but I'm not sure if the blame is going to the right place. Complex compilation process of OpenSSL is mostly coming from FIPS requirements as well and no platform or linker can prevent that, because the problem itself is not technical but bureaucratic. Some things just can't be avoided, but all ideas of how to make TLS upgrades less painful should be taken into account. As much as I'd like to design the protocol from scratch as well, it doesn't help if no one is going to use it.

Juho

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Nov 2013 20:50:34 -0800

TLS 1.2 solves the same problem as TLS 1.0. It should therefore have
the same API.
Somehow, having a state machine driven by data coming from a socket
driven by various options is
hard to design a good API around. (Seriously, transition(stateobject,
data_fed_in, length of data, data_maybe_coming_out, length_out) and
getcurrentstate(stateobject) together with some queries and setup of
options would do just fine.)

Part of the reason for the lack of updates is good Internet
citizenship brings no rewards. F5 customers don't give a damn about
holding the rest of
us back so long as that little lock icon still appears, embedded
device makers see no reason to upgrade, etc. Add this to the fight of
browser makers for market share, and anything that is good to do/has a
risk of breaking some sites will not get done.

The complexity of OpenSSL building, and most of the complexity of
OpenSSL is purely gratuitous. There is no reason it cannot be as clear
as the Go TLS library or PolarSSL.

This of course means that we have to live with whatever choices we
make for a long time, and ensure that implementations are simple
enough
to be bug-free.
Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Nov 2013 10:02:49 -0500

> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.

Do you really believe this or are you trying to just be provocative?

---

From: Watson Ladd <[email-masked]>
Date: Mon, 18 Nov 2013 08:34:43 -0800

> Do you really believe this or are you trying to just be provocative?
Do you really believe that backwards compatibility at the source level
had to be sacrificed?
Stable interfaces are the norm, unstable ones are remarkable. How many
prongs does a ground-fault detecting electricity socket have?
BLAS has multiple implementations, all with the same API. MPI looks
the same on a bunch of Xboxes wired together with Ethernet as it does
on a several million dollar supercomputer. GMP doesn't gratuitously
change its interface with every performance enhancement, and to this
day "Hello World" works unchanged on my machine, some 40 years after
it first ran on a PDP-11. Everything about the environment it runs on
is different, from the word size, to the endianness, to the output
mechanism, to the interface I am using. And yet it works with only a
recompile.

TCP has undergone many changes to the implementation, yet the BSD
sockets API still works. Why exactly does an application need to care
about which ciphersuite is used? Why does it need to do more than hand
over some trusted PKI roots, and a server certificate?

The current APIs have caused lots of security bugs as people don't use
them correctly. The solution: high level APIs that won't change when
the implementation is upgraded. Is this really too lofty a goal? The
costs of the current approach are obvious: what are the costs of
making better APIs?
Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Nov 2013 11:41:19 -0500

These seem contradictory to me:

> The current APIs have caused lots of security bugs as people don't use them correctly. The solution: high level APIs that won't change ...

The IETF has traditionally avoided API's and doesn't get involved in high-level language wars (other than ASN.1/DER vs ASCII art :)

	/r$

---

From: Andrei Popov <[email-masked]>
Date: Mon, 18 Nov 2013 19:02:02 +0000

Hi Yoav,

Yes, the percentage if servers that can't handle TLS1.2 or gracefully negotiate a lower protocol version is diminishing, but very slowly. From my perspective, enabling TLS1.2 by default is necessitated primarily by security and performance considerations (e.g. a chance to negotiate AES_GCM instead of RC4). However, for web browsers, enabling TLS1.2 by default means one more step in the sequence of (insecure) reconnect attempts with lower protocol versions.

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, November 17, 2013 3:13 AM
To: Hannes Tschofenig
Cc: [email-masked] list
Subject: Re: [TLS] Deployment ... Re: This working group has failed

Hi Hannes

Yoav

---

From: [email-masked] (Martin Rex)
Date: Mon, 18 Nov 2013 20:25:32 +0100 (CET)

Andrei Popov wrote:
> 
> Yes, the percentage if servers that can't handle TLS1.2 or gracefully
> negotiate a lower protocol version is diminishing, but very slowly.

Unfortunately, I've seen a new (government mandated) Web Service usage
scenario deployed in 2013 where the hardware SSL/TLS accellerater that
is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.

We really need to get rid of the dependency on ClientHello.client_version
being { 0x03, 0x03 } to use protocol features that can be implemented
with fairly little effort in TLSv1.0, thereby obviating the need
for reconnect fallbacks in clients -- a "feature" that most programmatic
TLS clients do not have, and that is susceptible to downgrade.

>
> From my perspective, enabling TLS1.2 by default is necessitated
> primarily by security and performance considerations (e.g. a chance
> to negotiate AES_GCM instead of RC4).

The interoperability problems from sending
ClientHello.client_version { 0x03,0x03 } are to serious and significant
to ignore, and the kludges (reconnect fallbacks) are to cumbersome
for most apps.

The _correct_ approach would be to publish how to use GenericAEADCipher
record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and
remove the braindead "must not send this ciphersuite with client_version
less that TLSv1.2" from the AES-CCM and AES-GCM documents.

rfc5746 deployed with significantly less interop problems than both
TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).

>
> However, for web browsers, enabling TLS1.2 by default means one more
> step in the sequence of (insecure) reconnect attempts with lower
> protocol versions.

Rather than bulding such kludges into Browsers, the implementers
should have come to the TLS WG help working on changes to TLS that
will make all desired TLS features work in a more backwards compatible
fashion than through kicking "client_version" / "protocol_version" fields.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 18 Nov 2013 20:32:07 +0100 (CET)

> our TLS WG chair) why things are progressing so slowly and what exactly 

The lack of real value in TLSv1.1, the additional weaknesses of TLSv1.2,
and the interoperability problem of sending ClientHello.client_version
with a value higher than { 0x03, 0x01 }.

Did any browser try to ship TLSv1.1 or TLSv1.2 without including
a reconnect fallback facility?  How many browsers did reconnect fallbacks
prior to using TLSv1.1 or TLSv1.2?

The reasons for TLSv1.1/TLSv1.2 not deploying is not very much different
from why IPv6 is not deploying.  Huge complexity and negligible value.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Mon, 18 Nov 2013 12:02:16 -0800

the same API.
>> The current APIs have caused lots of security bugs as people don't use
them correctly. The solution: high level APIs that won't change ...
The point is to do it right for both TLS 1.2 and TLS 1.0. If you expose
details you shouldn't you are not going to be able to keep them stable
or used correctly.
>
> The IETF has traditionally avoided API's and doesn't get involved in
high-level language wars (other than ASN.1/DER vs ASCII art :)
I vote ASCII art: it keeps the specs simple by imposing a cost on
complexity. Now, someone try making ASCII art for all of TLS.

As for the API issue, I am not suggesting that we standardize it anymore
than the IPSEC people standardized F/SWAN. Rather I am suggesting that we
view the lamentable state of the OpenSSL and NSS source code as problems
that are keeping RC4 alive.

If the WG wants to ignore the need for reference implementations and
interoperability testing fine. But that is not the way successful standards
have emerged from the IETF.

-- 
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

---

From: Geoffrey Keating <[email-masked]>
Date: 18 Nov 2013 13:41:56 -0800

[email-masked] (Martin Rex) writes:

> How many browsers did reconnect fallbacks prior to using TLSv1.1 or
> TLSv1.2?

I believe both Mozilla and Safari did this.  The first problem you hit
is not version number intolerance, but extension intolerance, and/or
SSLv2-only servers (depending on when this was implemented).  For
example, <https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c16>.

---

From: "Michael Staubermann" <[email-masked]>
Date: Mon, 18 Nov 2013 23:16:21 +0100

> Unfortunately, I've seen a new (government mandated) Web Service usage
scenario deployed in 2013 where the hardware SSL/TLS accellerater that is
being used is TLS version intolerant to TLSv1.1 and TLSv1.2.

On the other hand we have the (government mandated) requirement to use TLS
1.2 for governmental institutions:

https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2013/Mindeststanda
rd_TLS_1_2_Web-Seiten_des_BSI_13112013.html

Which translates into: 
"The Federal Office for Information Security (BSI ) has 8 October 2013 a
minimum standard for the use of a transport encryption using the TLS
protocol published . A minimum standard to be met by the BSI describes the
safety requirements for a product or service category or methods to achieve
a reasonable minimum protection against IT security threats . With the
release of minimum standards for TLS 1.2 , the BSI has formulated in terms
of Internet users in Germany set a target to which the institutions of the
federal government , including the BSI is now able to work towards.

It lies in the nature of a target that this is in the future. To specify a
destination that you have already achieved, makes little sense from the
perspective of the BSI.

Since migrating to TLS 1.2 usually includes not only software but also
hardware products, this can be a time-consuming process , involving not only
technical and organizational aspects are taken into account. In this
respect, even after the reduction of a specific objective for a transitional
period is quite common and useful. The BSI is accompanying this transition
period and is available to authorities in the migration advice. Also in the
BSI itself the migration takes place in a structured and carefully prepared
process. This process has already begun. Together with his hosting service ,
the BSI is currently working diligently to change the web server on which
the BSI own websites are hosted. First, it's about ending the exclusive use
of the RC4 encryption algorithm. This could already be realized in the short
term. The migration to TLS 1.2 is already initiated."

-mst

---

From: [email-masked] (Martin Rex)
Date: Mon, 18 Nov 2013 23:31:40 +0100 (CET)

Michael Staubermann wrote:
> https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2013/Mindeststandard_TLS_1_2_Web-Seiten_des_BSI_13112013.html

That is a misunderstanding.

This statement by the German BSI is a mere recommendation,
it is _not_ mandatory to use TLSv1.2.

You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?

The Web Service of the Portugal fiscal authority that businesses have
to submit certain data through a WebService _is_ mandatory.

-Martin

---

From: Joshua Davies <[email-masked]>
Date: Mon, 18 Nov 2013 16:40:03 -0600

> You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?

Really?  How so?  The only major difference (besides the new cipher suites
and modes and such) between TLS 1.1 and TLS 1.2 is the PRF - are you saying
that the TLS 1.1 PRF is stronger than SHA 256?  Has this been proven or is
that just conjecture?

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 Nov 2013 01:02:24 +0100 (CET)

> that the TLS 1.1 PRF is stronger than SHA 256?  Has this been proven or is

The TLSv1.1 PRF should be OK for 128-bit signature.

The weakness of TLSv1.2 is in the RSA signatures (digitally signed).
SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination
for digitally signed, which is stronger than SHA1 alone.

TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5), and
the latter is pretty far from 128-bit security.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 Nov 2013 01:03:48 +0100 (CET)

Resent (with correction) Sorry, I seem to be tired.

> > that the TLS 1.1 PRF is stronger than SHA 256?  Has this been proven or is
 
The TLSv1.1 PRF should be OK for 128-bit security strength.

-Martin

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 18 Nov 2013 18:48:52 -0800

> Do you really believe this or are you trying to just be provocative?

Watson's right.  OpenSSL is the norm and the OpenSSL API is
fundamentally wrong.  Let's see:

1. Defaults are insane.  (A crypto library should select a reasonable
set of cipher suites, for example.)  To make OpenSSL work decently, you
have to program a large array of poorly documented settings.  Want GCM?
 You have to ask for it.  (To make matters worse, OpenSSL's cipher suite
names don't match the RFC.)

2. New features need silly code in order to work.  Want DHE?  You need
to write code to feed OpenSSL a DH group.  Want ECDHE?  You need to call
a few poorly documented functions.  Want to support ECDHE with more than
one group (since the client can send a list)?  Oh wait, OpenSSL forgot
about that use case.  So, if and when curve25519 gets added to TLS, all
users of OpenSSL will need to start using a new API to support
curve25519 without losing P-256 support.

3. There are no useful diagnostics.  Want decent reports of why a
connection was rejected?  Good luck.  (I think I figured it out as long
as the client speaks SSL3 or higher, but I'm at a loss as to getting a
meaningful diagnostic for SSLv2.)

4. Want to do anything intelligent about certificate validation?  Good
luck understanding that API.

The world needs a good, permissively licensed,
hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
there is, and it has its set of issues, too.

--Andy

---

From: Kirils Solovjovs <[email-masked]>
Date: Tue, 19 Nov 2013 02:55:34 +0000

> fundamentally wrong.  Let's see:
1..4
> there is, and it has its set of issues, too.

Fully seconded, Andy!

Still.. what do you think should be done to alleviate this step by step?

Are you proposing to scrap openssl and start from scratch?

-- 
Kirils Solovjovs

---

From: Andy Wilson <[email-masked]>
Date: Tue, 19 Nov 2013 17:15:11 +1300

What about PolarSSL?

Surely there's discussions on the OpenSSL mailing lists about some of these
concerns

-- 
Regards

Andy

---

From: Marsh Ray <[email-masked]>
Date: Tue, 19 Nov 2013 05:44:41 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
> The TLSv1.1 PRF should be OK for 128-bit security strength.

TLS 1.1 https://tools.ietf.org/html/rfc4346#page-13
"   TLS's PRF is created by splitting the secret into two halves and
   using one half to generate data with P_MD5 and the other half to
   generate data with P_SHA-1, then exclusive-ORing the outputs of these
   two expansion functions together."

Good for 160 bits I figure?

TLS 1.2  https://tools.ietf.org/html/rfc5246#page-14
"   In this section, we define one PRF, based on HMAC.  This PRF with the
   SHA-256 hash function is used for all cipher suites defined in this
   document and in TLS documents published prior to this document when
   TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
   PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
   stronger standard hash function.
"
Sounds stronger to me.

> SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination for digitally
> signed, which is stronger than SHA1 alone.
> 
> TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5), and the latter is
> pretty far from 128-bit security.

But if the attacker can break MD5, he can exploit an MD5 cert chain, right? (e.g., Flamer)
If not, he can't negotiate the use of MD5 for signing the TLS handshake.

If the attacker can break SHA-1, he can exploit a SHA-1 trusted root, right?
If not, he can't negotiate the use of SHA-1 for signing the TLS handshake.

So TLS 1.2 just follows the convention established by the available trusted root CA. No configuration that could be stronger than SHA-1 can be weakened to SHA-1. Furthermore, no configuration that could be stronger than SHA-1+MD5 can be weakened to SHA-1+MD5.

Or am I missing something?

Are you saying that TLS 1.2 clients in practice MUST send md5 and sha1 in supported_signature_algorithms, even if they trust no MD5 or SHA-1 roots?

- Marsh

---

From: Ralf Skyper Kaiser <[email-masked]>
Date: Tue, 19 Nov 2013 09:17:41 +0000

I agree with Watson (high level API is needed. Desperately).

Whenever I do a source code audit I almost always find an implementation
bug, something where the developer just did not know how to use openssl
correctly and kind of guessed or googled the solution (and google is so
often wrong...).

A high level API that takes care of always the best settings and takes care
of certificates, revocation and pinning would fix a significant number of
security problems out there and lower the bar for other application to
start using TLS.

This is the wrong mailinglist to discuss it but it should be mentioned on
the openssl/gnutls mailinglist.

regards,

ralf

---

From: Ben Laurie <[email-masked]>
Date: Tue, 19 Nov 2013 09:38:11 +0000

> costs of the current approach are obvious: what are the costs of

I won't defend OpenSSL's APIs, because I agree they're pretty sucky,
but I do want to observe that the TLS API did not change between TLS
1.0 and 1.2, so I'm not really sure what you're talking about here.

---

From: Ivan Ristić <[email-masked]>
Date: Tue, 19 Nov 2013 13:13:00 +0000

To add to this discussion about protocol version intolerance, I've been
tracking this problem in my SSL Pulse data set (SSL servers from the
Alexa top 1 million).

Here's what I have for November:

  Total servers: 163,587

  TLS 1.0 intolerance        9
  TLS 1.1 intolerance    1,388
  TLS 1.2 intolerance    1,448 (~ 0.9%)
  TLS 1.3 intolerance   17,840 (~10.9%)
  TLS 2.98 intolerance 122,698 (~75.0%)

  Long handshake intolerance: 4,795 (~2.9%)

It seems to me that attempting to deploy TLS 1.3 would be very
difficult, considering how many servers are intolerant to this version
number. And TLS 2.x would be just hopeless.

Disclaimer: I have not spent as much time as I would have liked
validating these, but I don't have a reason to believe they are not correct.

-- 
Ivan

---

From: Zooko Wilcox-OHearn <[email-masked]>
Date: Tue, 19 Nov 2013 14:44:41 +0000

> Are you proposing to scrap openssl and start from scratch?

There are many alternatives to openssl. Wikipedia has a table:

https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations

That list is not complete — for example it omits Botan:

http://botan.randombit.net/tls.html

Oh, you require a permissive licence? Judging from the "Overview"
table on that wikipedia page, that narrows it down to NSS or Botan for
you.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 19 Nov 2013 10:54:40 -0500

Would a practical solution be to do a TLS 1.2.1 update that:

1. Keeps the same TLS version in the ClientHello as 1.2,
2. Adds new mandatory cipher suites (as needed),
3. Adds a fast negotiation extension (as needed/if possible), and
4. Deprecates (but does not remove) any 1.2 cipher suites we know to be broken.

The goal would be backwards-compatibility with TLS implementations that support (or at least gracefully negotiate down from) 1.2.

(IANAC (I am not a cryptographer), I just use a lot of TLS libraries and don’t know whether this is workable…)

>> fashion than through kicking "client_version" / "protocol_version" fields.

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Nov 2013 08:06:33 -0800

On Tue, Nov 19, 2013 at 7:54 AM, Michael Sweet <[email-masked]> wrote:

> The goal would be backwards-compatibility with TLS implementations that
> support (or at least gracefully negotiate down from) 1.2.
>

If the version number is the challenge, we may have to do something like
that.

I suggest we hold off on this question until we have a better sense of what
exactly
we want to stuff in TLS 1.3 and which pieces of it are going to be
compatible
versus just switch-hitting.

Best,
-Ekr

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 Nov 2013 17:21:02 +0100 (CET)

Marsh Ray wrote:
> > TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5),
> > and the latter is pretty far from 128-bit security.
> 

An MitM-Attacker could send an TLS signature algorithms extension
with only (rsa,md5) and (EC)DHE_RSA cipher suites to the server
to obtain large amounts of (rsa,md5) signed (EC)DHE parameters
and then try to have the client accept (rsa,md5) signed (EC)DHE
parameters.  This is entirely independent of the signatures on
the certificates.

> 
> Are you saying that TLS 1.2 clients in practice MUST send md5 and sha1
> in supported_signature_algorithms, even if they trust no MD5 or SHA-1 roots?

This isn't about the highest security level that cooperating TLS peers
might achieve, but the lowest security level that an MitM attacker can
coerce the peers to perform.

The TLS v1.2 signature algorithms extension should have NEVER conflated
"digitally-signed" algorithms with signatures on certs, and it should
have NEVER allowed anything less than SHA1+MD5 with rsa for use in
digitally signed.  We can re-use the digitally-signed TLSv1.2 PDU
changes to make the signalling available in all versions of TLS,
but the TLSv1.2 signature extension in ClientHello is for the trashcan.

-Martin

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 19 Nov 2013 11:35:32 -0800

>> Still.. what do you think should be done to alleviate this step by step?

There may be some benefit to having a real specification of what an
implementation should provide.  On the other hand, getting this right
may be impossible.

> table on that wikipedia page, that narrows it down to NSS or Botan for

I don't personally require it, but many people probably do.  I think the
real issue is that the world seems to have standardized on an awful
implementation, and that said awful implementation probably gets the
most careful review.

I also doubt that this can be solved by policy.

Perhaps, though, IETF could publish a small list of features that TLS
implementation SHOULD offer.  For example:

 - Support any legal combination of ciphers, key exchange mechanisms,
etc. out of the box, without additional configuration, unless disabled
by the user, for security reasons, or for IP reasons.  For example,
failure to support non-P-256 curves because no curve was selected or
because P-256 was selected should violate this rule (hello, OpenSSL).

 - Support multiple clients in the same process linked against the same
library without causing those clients to interfere with each other
(hello, GnuTLS).

 - When in client mode, implementations MUST refuse to connect to a
server unless an explicitly chosen set of trust roots (or other
mechanism such as DANE) authenticates that server (hello, everything).

 - Standardize on an (abstract) representation of a certificate chain
and standardize an API for doing PKIX verification.  (There's lots of
freedom here, but I guarantee that OpenSSL's approach is wrong.)

There could also be an official (or semi-official) list, updated from
time to time, of what a TLS implementation must do to be considered
secure.  For example, right now I'd want to check that the
implementation I use does 1/n-1 record splitting, uses a true
constant-time CBC MAC implementation, gets GCM right, etc., and I
probably don't know the full list.

Still, creating good software by fiat is hard.

--Andy

---

From: [email-masked] (Martin Rex)
Date: Tue, 19 Nov 2013 20:49:48 +0100 (CET)

>    stronger standard hash function.

The weakest link in the chain determines the strength, not the
strongest link in the chain.

NIST SP800-57 provides the following guidance on strength:

Bits of   symm.    FFC       IFC     ECC     Hash     Hash     Hash
security cipher  (DSA/DH) (e.g.RSA)         DigSig    HMAC   KeyDeriv

  80     2TDES    1024/160   1024  160-223   SHA-1    SHA-1    SHA-1
 112     3TDES    2048/224   2048  224-255  SHA-224   SHA-1    SHA-1
 128    AES-128   3072/256   3072  256-383  SHA-256   SHA-1    SHA-1
 192    AES-192   7680/384   7680  384-511  SHA-384  SHA-224  SHA-224
 256    AES-256  15360/512  15360   512+    SHA-512  SHA-256  SHA-256

So for use with RSA-2048 certs and AES128 encryption, the
TLSv1.0/v1.1 PRF should be OK.  You may want to look at how
many signatures in certificates, CRLs, OCSP, etc. still use
SHA-1, and where this gets you in the above table.

-Martin

---

From: Patrick Pelletier <[email-masked]>
Date: Tue, 19 Nov 2013 21:05:54 -0800

> library without causing those clients to interfere with each other

What's the issue that GnuTLS has with this?  I'm more familiar with the 
issue OpenSSL has, namely that it requires threading callbacks to be 
set, so each client in the same process is going to be stomping on the 
same set of global callbacks.  I'd thought GnuTLS was better about 
global state, but maybe there's something I've missed.

Also, I thought Botan wasn't good on this point either, since it 
requires a LibraryInitializer object to be created, and (I thought) it 
doesn't support more than one LibraryInitializer existing at once.

--Patrick

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 19 Nov 2013 22:24:03 -0800

On Tue, Nov 19, 2013 at 9:05 PM, Patrick Pelletier
<[email-masked]> wrote:
> issue OpenSSL has, namely that it requires threading callbacks to be set, so
> each client in the same process is going to be stomping on the same set of
> global callbacks.  I'd thought GnuTLS was better about global state, but
> maybe there's something I've missed.
>

GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it
manipulates global state, and it sometimes causes things to
malfunction after forking.  gnutls_global_init is documented as being
unsafe if called from multiple threads, which seems silly.

(As an even more off-topic aside, how is there nothing better than
pkcs11 for interfacing with abstract keys?)

> Also, I thought Botan wasn't good on this point either, since it requires a
> LibraryInitializer object to be created, and (I thought) it doesn't support
> more than one LibraryInitializer existing at once.

No clue -- I've never used it.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 27 Nov 2013 10:54:09 -0500

> unsafe if called from multiple threads, which seems silly.

fwiw, p11-kit (which gnutls integrates by default) is designed
specifically to solve the concurrency issue.  So iiuc, the only way to
trigger the concern about gnutls_pkcs11_init above is if you use
something other than p11-kit to handle pkcs11 modules.

> pkcs11 for interfacing with abstract keys?)

it's a shame, isn't it?  Stef Walter addresses this question too in his
response to the issues with gnutls_pkcs11_init:

http://lists.freedesktop.org/archives/p11-glue/2013-November/000397.html

Regards,

        --dkg

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 Nov 2013 17:54:54 -0600

All of this is off-topic for this list.  I'll post a reply anyways, and
I apologize to the list.

On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote:
>                     [...].  gnutls_global_init is documented as being

Initialization is not thread-safe in OpenSSL either.  This is a terrible
thing.  It *can* be made thread-safe, so there's no excuse for it not
being thread-safe.

> malfunction after forking.  [...]

PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs).

Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be
fork-unsafe for at least open sessions/objects on tokens that require
authentication (PIN).  That's because any library using file descriptors
where offset is not a relevant concept will necessarily be fork-unsafe
by default.  And: any stateful cryptography library (e.g., an
implementation of TLS) will tend to be fork-unsafe (imagine a process
trying to use a TLS connection on both sides of a fork()!).

Of course, that's all rather POSIX-specific, but the problem is inherent
to any fork()-like interface.  Use posix_spawn() or similar, then you
won't have to worry about fork-safety at all.  Long ago I used to think
fork+exec superior to spawn since spawn was easy to implement in terms
of fork+exec, but in truth fork() is a dangerous and difficult-to-use
interface -- the only safe things to do on the child side of fork() are:
async-signal-safe things, culminating in _exit() or exec*() ASAP.

> pkcs11 for interfacing with abstract keys?)

Not really, not portably, not to my knowledge :(  Something better is
badly needed, yes.

In particular we need: a) decent APIs for software crypto (even if it
uses specialized HW under the covers), b) decent APIs for talking to
smartcards (tokens), including softtokens, c) decent APIs for
cryptographic protocols, d) decent APIs for PKIX naming, ...

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 28 Nov 2013 10:10:30 +0100

> thing.  It *can* be made thread-safe, so there's no excuse for it not
Hello,
 I don't understand why this is an issue since it is documented. If a
function (like a global initialization function) is supposed to create
the mutexes for the rest of the library functions it cannot be expected
to be thread safe; at least in a portable way since static
initialization of mutexes is not a portable thing.

Nevertheless, even if you really need to call a global initialization
function in every thread you create (I really don't see why), you can
simply call it in a locked mutex. 

> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs).

It requires some reinitialization on every fork. Again if that is
documented it can be made to work. I agree, it is a PITA to handle
though.

regards,
Nikos

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 29 Nov 2013 15:35:43 -0800

> simply call it in a locked mutex.

No, I can't.  I occasionally use libraries, and those libraries in
turn use GnuTLS.  Requiring those libraries to force their users to
synchronize their initialization of GnuTLS sucks.

If GnuTLS really must use global state in a manner that isn't
transparent to its users, it should get the synchronization right.

Any self-respecting pthreads implementation should implement
PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes
its data, making it completely safe.  An even better solution would be
to use pthread_once.

--Andy