Re: Misconceptions about the GSS-API

On Fri, Jul 13, 2012 at 5:04 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Jul 13, 2012 at 3:37 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
>> 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.

And intend to remain so unless you can identify the small subset that
is needed and separate it out from all the rest.

Oh and explain the whole project in terms of bits on the wire rather
than multi-tiered abstractions that mean something to people with
decades of experience of GSS-API but nothing to the rest of us.

I have been in the business of Web Security twenty years as of
September. In all that time the only people who have ever brought up
the issue of support for it have been GSS-API developers. I have never
once had a customer ask for it.



> 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

You still don't get our point. How does this call relate to HTTP? What
data objects are produced? What do they look like on the wire? How
does it affect protocol state?

What you have there is not a protocol, it is an implementation.

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

Assuming that we embed your library into all the clients and servers.

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

This is about the choice of a protocol, not an API.

-- 
Website: http://hallambaker.com/

Received on Friday, 13 July 2012 21:19:25 UTC