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

[Kyle Hamilton <[e-mail]>]

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" <[e-mail]>
wrote:

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