Re: Web Keys and HTTP Signatures

On 04/18/2013 01:54 AM, Carsten Bormann wrote:
> On Apr 18, 2013, at 02:22, "David I. Lehn" <dil@lehn.org> wrote:
>> if you find security issues
> 
> Wrong question.
> 
> A security spec is worthless if it doesn't establish useful security
>  properties.

Correct. I think Dave Lehn was making a general statement "If you find
more issues, please let us know.", he was not asking a question. I
believe that you are talking past what he was saying.

You also seem to be implying that you know of which security properties
are not being established by http-signatures. Could you please elaborate?

> The spec needs a good look from people with more security mojo.

We agree, which is why we published an implementation, pointed to the
spec, and cc'd the IETF HTTP WG. A very positive thing has come out of
that, which is that an issue was found with the spec and implementation.

> (Or maybe it can simply be replaced by one of the more learned 
> attempts under discussion, see 
> http://www.ietf.org/proceedings/85/minutes/minutes-85-httpauth 
> http://www.ietf.org/proceedings/86/minutes/minutes-86-httpauth for 
> some links.)

Thanks for the link. We've looked at a number of those before, or
variants of the approaches. Here's feedback on each:

HTTP Origin-Bound Authentication (HOBA)
http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt

We had considered signatures in the URL in the second approach to the
problem in the Web Keys spec. We eventually rejected the solution
because of limitations in the URL length in some browsers and because we
wanted the semantics of the HTTP headers to be able to be a part of the
digital signature. We also didn't want large signed messages being
dumped to the webserver logs (the request line is typically included).
So, while HOBA does solve the problem, it doesn't solve it in a way that
is acceptable to us.

HTTP Mutual Authentication
http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12

Overkill for our purposes and requires multiple bounces back and forth
between the client and the server. Key exchange isn't required since
that's taken care of by the Web Keys PKI framework. We don't intend the
Web Keys HTTP signature protocol to be session-based, as a session-based
value can be built on top of HTTP signatures pretty easily.

HTTP Multilegged Auth
http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt

Seems like overkill for our needs and is fairly specific to HTTP 2.0. We
wanted something that could work for HTTP 1.0. Multi-legged
authentication is something that we're not interested in solving using
HTTP Signatures. Putting state into the protocol is something we'd like
to avoid if possible.

HTTP Salted Challenge Response
http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00

Uses HMACs, doesn't use public key crypto, which is a requirement for
Web Keys and the Web Payments work.

HTTP REST Auth
http://tools.ietf.org/id/draft-williams-http-rest-auth-03.txt

This was the solution that seemed to be most interesting to the Web Keys
and Web Payments work. However, it requires quite a bit of state to be
remembered by the server (the Session URIs). Keeping the state of a
"session" around isn't desirable. We didn't want there to be a concept
of logging in and logging out of a website w/ the HTTP Signature stuff.
We'd rather that sessions are built on top of HTTP Signatures via a HTTP
header or cookie. Again, if we had to pick a back-up solution, HTTP REST
Auth seems like it might work for us, but we'd rather not use if we
don't have to.

Hopefully this explains why we haven't picked any of the solutions that
you outlined in your response. Web Keys + HTTP Signatures are simpler,
and we're now in the discovery phase to see if the protocol will stand
up to scrutiny by the security community.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Thursday, 18 April 2013 16:20:07 UTC