W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Content-Integrity header

From: HAYASHI, Tatsuya <lef.mutualauth@gmail.com>
Date: Tue, 10 Jul 2012 04:08:48 +0900
Message-ID: <CAGipQFkB0KR0r+cHGqyYDVm-1nGt-=78ydmehUZyBOHp+tJ-Qg@mail.gmail.com>
To: ietf-http-wg@w3.org
Cc: Phillip Hallam-Baker <hallam@gmail.com>, James M Snell <jasnell@gmail.com>

I know that this is demanded.
When I discussion about http-authentication and phishing,
it is requested by many people.
It is a difficult problem.
ex) proxy...

I think that it is good to do this discussion now.


On Sat, Jul 7, 2012 at 8:23 AM, James M Snell <jasnell@gmail.com> wrote:
> In general, I'm +1 on the general idea albeit with a few caveats...
> 1. To minimize complexity, only a single Content-Integrity header
> should be used. I don't want, as Roy points out, to have to iterated
> through a bunch of unsupported header values looking for the one I
> want. Just as it makes very little sense for an implementor to provide
> multiple Last-Modified, Etag and Content-Type headers in a single
> message; there should be only a single Content-Integrity statement and
> I either understand it or I don't.
> 2. The performance impact of calculating the digest needs to be
> carefully considered. I'd rather not be required to buffer a full
> representation in memory all the time just to calculate a header
> value. I know it's largely unavoidable, but perhaps there's some
> currently elusive solution that can be considered. For instance..
> allowing Content-Integrity to appear as a trailer at the end of a
> chunked response.
> 3. Something needs to be said about what happens if the
> Content-Integrity check fails. For instance, if a request containing
> Content-Integrity is sent to the server and the server detects that
> the signature is invalid, what should happen? what must happen?
> Likewise, how are intermediaries expected to treat the
> Content-Integrity header given that any intermediary is able to modify
> the payload at any time?
> - James
> On Fri, Jul 6, 2012 at 3:12 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> Someone pointed me to this in a private message:
>> http://tools.ietf.org/html/rfc3230#section-4.3.2
>> This is a Proposed Standard and defines a Digest header that covers
>> the digest only functionality.
>> The digest header is not really suited to extension so that suggests
>> that a MAC only header such as Content-MAC or MAC would be more
>> appropriate.
>> On Fri, Jul 6, 2012 at 2:43 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> HTTP 1.0 specifies a header Content-MD5.
>>> This is a bad header for all sorts of reasons, not least that the
>>> header was added despite the fact that I told people that MD5 had just
>>> been severely compromised. In particular there is only one digest
>>> algorithm specified and no way to use others.
>>> A better approach would be:
>>> Content-Integrity: <base64-value> ;alg=<ID>
>>> For many Web Services, what we would like to do is to specify a MAC
>>> rather than a digest and to use a preshared key identified by some
>>> form of kerberos-like ticket. We don't need to specify the internal
>>> structure of the ticket, just accept that we will have some sort of
>>> key exchange service interaction at the end of which the client ends
>>> up with a shared secret, an algorithm and an identifier that can be
>>> passed to the service where the interaction takes place:
>>> Content-Integrity: <base64-value> ;ticket=<ticket-data>
>>> Note that the method of establishing that ticket in the first place is
>>> out of scope for HTTP. Just think of it as something akin to a cookie.
>>> There are many ways that structure can be established but those are
>>> for the Web Service to manage, not something we should bind into HTTP.
>>> This approach is of course very similar to the www-authenticate header
>>> but with the major distinction that WWW-Authenticate is really about
>>> key establishment and this is a mechanism to apply the result of a key
>>> establishment to a content payload. But I guess if people think it
>>> better to re-use WWW-Authenticate than to introduce a new header, I
>>> can go with that.
>>> The way we authenticate Web Services transactions today is of course
>>> through either TLS or by embedding the authentication data into the
>>> content through something like JSON Signature or XML Signature or via
>>> something like WS-*. I don't particularly like these approaches as the
>>> content authentication is really meta-data for the content and that
>>> means it belongs in the HTTP header and not in the transport layer or
>>> in the content itself. That is what the HTTP headers are there for,
>>> making meta-data statements about the content.
>>> We seem to have got into a position where Web Services means 'just run
>>> over HTTP as if it was TCP/IP with firewall bypass'. I think we could
>>> make Web Services a lot simpler by using HTTP for the purpose it was
>>> intended and not duplicating that functionality in SOAP or whatever.
>>> I have discussed this with David Crocker and his DOSETA scheme. I
>>> think this is a case where if HTTP has the right socket, we can both
>>> plug into it.
>>> --
>>> Website: http://hallambaker.com/
>> --
>> Website: http://hallambaker.com/

HAYASHI, Tatsuya
Lepidum Co. Ltd.
Received on Monday, 9 July 2012 19:09:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:04 UTC