[TLS] Deployment ... Re: This working group has failed

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:
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>