Re: Web Keys and HTTP Signatures

[Stephen Farrell <[e-mail]>]

On 04/18/2013 02:55 PM, Amos Jeffries wrote:
> On 19/04/2013 1:42 a.m., Manu Sporny wrote:
>> On 04/17/2013 08:00 PM, Martin Thomson wrote:
>>> Yeah, that's a pretty bad.  Switching two date-formatted headers
>>> might be a simple thing to gain advantage on.  (Last-Modified and
>>> Date, might work to poison a cache with old content if the cache
>>> isn't rigorous about checking Date).  It seems like a simple fix
>>> would be to include the list of headers under the signature as the
>>> first item.
>> Carsten, James, Martin - good catch, thanks. We had assumed that the
>> implementation included the headers names as well as the values in the
>> data being digitally signed. As Dave Lehn pointed out, this is a work in
>> progress, but we wanted to get something out as sooner than later.
>>
>> The attack is only possible if a message is passed over a non-secure
>> channel, right? That is, the spec is clear about passing all messages
>> over HTTPS. Granted, that's not an excuse for the approach taken and it
>> should be fixed, but the attack is only possible if messages are sent
>> over an insecure channel, correct?
> 
> We had this argument out in the Bearer auth discussions. HTTPS is just
> one layer of security, it can (and routinely is) broken into by
> transparent proxies.
> 
> Your auth scheme needs to be as self-contained as possible and take
> advantage of every little bit of security that it can do without relying
> on external layers such as the SSL/TLS layer. It is better to be
> doubly-strong when HTTPS works than to depend on it alone break at the
> first sign of trouble.
> 
> IMO signed message schemes like this stand a far better chance of being
> rolled out if they work on plain-HTTP. There are a number of web
> applications and service which require security without the sledgehammer
> and limitations of TLS.

And in the "other relevant work" thread, aside from httpauth
(where I'm a co-author on a similar-ish proposal [1] and be
happy to chat about it, maybe the http-auth list is better
though), there's also work to use DKIM-like headers for
iSchedule [2]. I've not read this though (yet) to see if
they're all really that different or not.

Cheers,
S.

[1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba
[2] http://tools.ietf.org/html/draft-desruisseaux-ischedule