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

[Andy Lutomirski <[e-mail]>]

On 11/19/2013 06:44 AM, Zooko Wilcox-OHearn wrote:
> On Tue, Nov 19, 2013 at 2:55 AM, Kirils Solovjovs
> <[e-mail]> wrote:
>>
>>> 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.
>>
>> Fully seconded, Andy!
>>
>> 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.

>>
>> 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.

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