[TLS] TLS abstract API (Re: The risk of misconfiguration)

Nico Williams <nico@cryptonector.com> Thu, 08 May 2014 01:33 UTC

MIME-Version: 1.0
Date: Wed, 07 May 2014 20:33:32 -0500
Message-ID: <CAK3OfOiAP6fWPeVtbE0OB4bbgp+wOUMXPY0RuAfnZF2j=vBMZw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4FP54o0LRRSAmdfYFgstKyJGKVU
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] TLS abstract API (Re: The risk of misconfiguration)
Precedence: list

On Wed, May 7, 2014 at 7:58 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On May 7, 2014 5:15 PM, "Viktor Dukhovni" <viktor1dane@dukhovni.org> wrote:
>> The solution to avoid accidental use of NULL ciphers is in the
>> client API, no client HELLO should ever include a mixture of NULL
>> and non-NULL ciphers-suites.
>
> Why not make that a MUST in the RFC, and the same for anonymous DH? [...]

No objection from me!  HOWEVER, TLS is a protocol and does not come
with a standard API, not even an abstract API.  The most likely result
will be a handful of requirements and recommendations for APIs, but
nothing like an abstract API, or even a big picture.

I've long been saying that lack of abstract APIs is a big problem for us.

Protocols that lack APIs but would greatly benefit from having them:

 - IPsec (see Solaris' IP_SEC_OPT socket option)

 - PKIX (geez, PKIX naming is bloody painful; an API would help a lot)

 - TLS ('nuff said)

 - SASL (it has one, it's called Cyrus SASL, snark)

 - DNS[SEC]

and many others.

Not every protocol needs an API (e.g., SSHv2 doesn't, but then there
are plenty of SSHv2 libraries now, so maybe it does).

But TLS sure does need one.

Nico
--

[TLS] TLS abstract API (Re: The risk of misconfig… Nico Williams