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

[Andy Lutomirski <[e-mail]>]

On 11/18/2013 07:02 AM, Salz, Rich wrote:
>> 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?

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