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

Re: MACing HTTP requests/responses (Re: Content-Integrity header)

From: James M Snell <jasnell@gmail.com>
Date: Thu, 12 Jul 2012 10:40:00 -0700
Message-ID: <CABP7RbeXr6OAT7Cbv2xLUq9WvGiiiGbuTyjnxpOtmhLz-pPttA@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: Nico Williams <nico@cryptonector.com>, ietf-http-wg@w3.org
On Thu, Jul 12, 2012 at 9:32 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> I suspected as much, but is 're-invent chunked in HTTP/1.1' any more
> practical than 'make chunked worked in HTTP/1.1'.

Unfortunately no. For 1.1 it would appear that the only practical
approach would be An Ugly Hack at either the content or
content-encoding level, neither of which are great options for many
obvious reasons.

> This might be something that we just need to make happen in HTTP/2.0
> as part of multiplexing. I am willing to spend some of my personal
> time on that.

+1 ... I would very much like to see integrity checking added to
http/2.0 as well as a stronger requirement to support trailers in

> From a Web Services point of view, I think we can manage with an
> integrity header for cases where we need to support intermediaries and
> restrict trailers to cases where we don't. In most cases we are going
> to be layering over TLS in any case.
> I am not really proposing this header to compete with TLS. The reason
> I want it is to enable a closer binding of the authentication layer to
> the content than I can get in TLS. In particular I observe that:
> HTTP + JSON + Integrity Header ~= WS-*
> I can't run TLS on the type of processor typical in embedded systems
> for all sorts of reasons. But I can get a JSON stack and a frame
> around it.
> On Thu, Jul 12, 2012 at 12:19 PM, James M Snell <jasnell@gmail.com> wrote:
>> On Wed, Jul 11, 2012 at 6:51 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> What are the problems inherent in using Content-Integrity as a Trailer?
>>> Do the legacy clients botch chunked encoding?
>> Well, it appears that many existing 1.1 client, server and
>> intermediary implementations have taken the "trailers are optional"
>> idea to the extreme and either (a) provide no means of appending
>> trailers to the output, (b) provide no means of accessing trailers
>> included in the input or make it quite a bit more difficult to get to
>> them or (c) do not properly forward trailers on as a chunked message
>> flows from hop-to-hop. It's not clear at this point exactly how
>> widespread this problem is but it appears pervasive enough to make a
>> trailer-based content-integrity option problematic at best.
>> - James
>>> On Wed, Jul 11, 2012 at 7:44 PM, James M Snell <jasnell@gmail.com> wrote:
>>>> Phillip, just want to make sure that I'm keeping up with the
>>>> conversation thus far... Because of the problems inherent in using
>>>> Content-Integrity as a Trailer, is the idea then that
>>>> Content-Integrity would be a standard Header and that a new Transfer
>>>> or Content Encoding would be defined that supports an incremental
>>>> integrity check as a component of the encoding?
>>>>   GET /some/uri HTTP/1.1
>>>>   Host: example.org
>>>>   TE: integrity
>>>> For instance... something like...
>>>>   HTTP/1.1 200 OK
>>>>   Content-Type: application/octet-stream
>>>>   Content-Integrity: SHA-256; modifier=123...; param="..."
>>>>   Transfer-Encoding: integrity
>>>>   10
>>>>   {chunk of bytes}
>>>>   {digest}
>>>>   10
>>>>   {chunk of bytes}
>>>>   {digest}
>>>>   0
>>>> - James
>>>> On Wed, Jul 11, 2012 at 4:07 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>>>> On Wed, Jul 11, 2012 at 2:43 PM, Nico Williams <nico@cryptonector.com> wrote:
>>>>>> I agree that we need something better, and in particular that we ought
>>>>>> to have a MAC instead of a plain hash.  The problem with a MAC is:
>>>>>> whence the key?  Also, what should the MAC be applied to?
>>>>> The MAC should be applied to the 8-bit clean message content (i.e.
>>>>> precisely that which is bounded by Content-Length)
>>>>> If we are talking about Web Services then the key would be established
>>>>> through some application layer key exchange (TBS).
>>>>> The key requirement from a performance standpoint as I see it is that
>>>>> the server has to be able to operate in a stateless fashion which
>>>>> means using a ticket like approach.
>>>>>> Using a MAC, having a shared session key, ties into HTTP
>>>>>> authentication.  We can definitely have a generic MAC for HTTP and say
>>>>>> that HTTP authentication mechanisms that can should output session
>>>>>> keys.  And the HTTP authentication would also have to take care of MAC
>>>>>> algorithm negotiation.  I'd be quite happy with this approach.
>>>>> I think that there is definitely an opportunity to make use of a
>>>>> ticket mode to tie the HTTP authentication to the HTTP channel.
>>>>>> One issue with this approach is: if we always use TLS (but we might
>>>>>> not), why do the extra session crypto?  What do we gain?  Do we need
>>>>>> to worry about content re-writing proxies, say, as in some 3G
>>>>>> networks?  If we always use TLS then it suffices to ensure that a) TLS
>>>>>> provides confidentiality protection, b) the server cert remains the
>>>>>> same for the length of the login session, c) we have a unique,
>>>>>> unpredictable session ID in the headers (what we might call a cookie,
>>>>>> though we don't want it to be a cookie as such).
>>>>> TLS is very large, very complex and was engineered from the assumption
>>>>> that there would be public key credentials on the client. Yes, people
>>>>> can train it to do other tricks, but doing that is a lot more complex
>>>>> than doing what we need in HTTP.
>>>>> In my particular Web Service I am using TLS but still want to have a
>>>>> transport layer authentication protection because I don't want to do a
>>>>> TLS public key negotiation on each transaction and I don't want to be
>>>>> bound to TLS session expiry.
>>>>> In a large commercial environment the TLS processing is often
>>>>> completely offloaded onto an accelerator that strips out the TLS and
>>>>> hands clean IP packets to the Web Service. Another frequent screw case
>>>>> is TLS proxies like bluecoat devices.
>>>>> But even in the simplest TLS use case, the TLS security context is
>>>>> really not exposed to the Web Server or the client in the way you
>>>>> would need to use it for Web Services authentication in the commonly
>>>>> used APIs. The problem is that TLS is designed to conceal all the
>>>>> complexity of crypto from the application. That is why it was called
>>>>> SSL at the start.
>>>>>> In one post you talked about sequencing and replay protection for
>>>>>> chunks.  Adding that to the MAC really gets us close to the MIC token
>>>>>> features/design from RFCs 1964/4121 (Kerberos GSS mech).  We're
>>>>>> talking about having a sequence number.  As you say: this isn't
>>>>>> difficult; we've been doing this for a loooong time in Kerberos land.
>>>>> Heh, you could use a Kerberos token in my Omnibroker protocol if you
>>>>> wanted to. But since it is an opaque string of bytes as far as the
>>>>> client is concerned, well there is no reason to tie it to any one
>>>>> approach.
>>>>> People have been using kerberized cookies for years. The problem being
>>>>> that the cookie is not at all bound to the requests or responses.
>>>>>> Note that there's no need for sequence numbers to randomized given
>>>>>> that we have session keys, but sequence number windows add to the
>>>>>> state to be kept on the server side -- can we tolerate that? Note that
>>>>>> while session key state might be kept on the client in an encrypted
>>>>>> state ticket, session number windows cannot safely be kept that way --
>>>>>> they must be kept locally.  I tend to think that sequencing and replay
>>>>>> protection are the responsibility of the application -- all it needs
>>>>>> to do is add a sequence number to the chunks and manage its own
>>>>>> [per-resource] sequence number windows.
>>>>> The way I was thinking of helping the application was to provide a
>>>>> feature that allows Content-Integrity header to specify a key modifier
>>>>> as well as a ticket. The key used to calculate the MAC would then be
>>>>> the XOR of the modifier and the authentication key associated with the
>>>>> ticket.
>>>>>> Altogether we need: a session key identifier in the headers (this
>>>>>> should imply algorithm selection), a direction identifier (or separate
>>>>>> keys for each direction), a sequence number if we need sequencing
>>>>>> and/or replay detection, what content to MAC, and the MAC itself.
>>>>> Direction is already implicit in HTTP requests/responses.
>>>>> I don't think we need sequencing, we do need a modifier capability though.
>>>>>> Regarding what to MAC: the direction flag (unless we have diff keys
>>>>>> for each direction), the channel binding for the TLS channel (if we
>>>>>> have it), the URL?, some subset of headers? and the body.  Note that
>>>>>> applying the MAC to any headers requires that we say something about
>>>>>> canonicalization (e.g., "use the headers exactly as sent") and
>>>>>> canonical order (if a subset of headers) (e.g., "in the relative order
>>>>>> of appearance").  Header and body content need to be unambiguously
>>>>>> separated in the MAC input.  Obviously we can't MAC all headers: some
>>>>>> might be added by proxies, for example.
>>>>> I don't see the need to MAC any headers for a Web Service application.
>>>>> Put all the information in the content block.
>>>>> Otherwise we would have to do the sort of thing that DKIM does to sign
>>>>> headers and copy them.
>>>>> --
>>>>> Website: http://hallambaker.com/
>>> --
>>> Website: http://hallambaker.com/
> --
> Website: http://hallambaker.com/
Received on Thursday, 12 July 2012 17:40:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 July 2012 17:40:55 GMT