- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Fri, 13 Jul 2012 17:18:57 -0400
- To: Nico Williams <nico@cryptonector.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
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