Re: Misconceptions about the GSS-API

On Fri, Jul 13, 2012 at 3:37 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <CAK3OfOhrjOTa5miWJdDd4_gEHHCD4rODwjwtEQz248yfqfjueg@mail.gmail.com>
> , Nico Williams writes:
>
>>3) The GSS-API is a very large API, yes, but typical applications use
>>only a very small subset of the available GSS functions.
>
> Just out of curiosity:
>
> Does that really sound like good security engineering for a
> narrow-scope protocol like HTTP/2 to you ?
>
> It certainly sounds wrong to me.
>
> It almost certainly IS wrong, if the goal is to get as many mediocre
> programmers as possible to implement protection correctly.

There are many enormous APIs out there where only a small subset is
necessary for common applications.  The functions that most GSS
applications don't need are not functions that you can shoot your feet
off with.  It sounds to me like you're not familiar with the GSS-API.

> One of the main reasons Varnish does not support HTTPS is the the
> quality of the APIs available, and the elephantine amounts of
> needless generality behind them.

APIs like OpenSSL's are awful, I give you that.  If you used the
GSS-API as an interface to TLS you'd have a very trivial client,
particularly for anonymous clients.  You'd only need these functions:

 - GSS_Import_name(), which you'd call to get a NAME object
corresponding to the server's hostname
 - GSS_Init_sec_context(), which you'd call with that NAME object, the
mechanism OID for TLS, and all default arguments
 - GSS_Wrap() and GSS_Unwrap() to implement the application record layer
 - GSS_Release_name(), GSS_Deleset_sec_context(), and
GSS_Release_buffer() to release resources

That's *it* (oh, and GSS_Display_status() to get printable errors).
All the complexity of validating the server cert and ensuring that it
is good for the given hostname would be buried in the mechanism.  If
you need to specify different trust anchor sets for different hosts
that would require one more function (though the GSI TLS mechanism
doesn't support it, but I could make sure it gets added...).

> I know crypto is never simple, but arguing that it comes with a lot
> of complexity that most users don't need, is not a winning argument
> in my book.

It really pains me to see you say this about GSS -- you don't know,
you can't know, because you'd not say that if you knew it.  OpenSSL's
APIs are an utter usability disaster.  GSS' aren't.

> Crypto for HTTP/2.0 should be specified in a way which is very hard
> to do wrong, not very hard to do right.

I agree violently.

Nico
--

Received on Friday, 13 July 2012 21:05:05 UTC