[OAUTH-WG] MAC - body hash and response body hash and cache-control headers

Peter Wolanin <peter.wolanin@acquia.com> Sat, 18 February 2012 20:53 UTC

Received-SPF: pass (google.com: domain of peter.wolanin@acquia.com designates 10.50.203.66 as permitted sender) client-ip=10.50.203.66;
MIME-Version: 1.0
Date: Sat, 18 Feb 2012 15:53:19 -0500
Message-ID: <CAH0thKDXpSCNutS88dkJ4i9rutpdu-UYHip1SDk+UriRdM+MEw@mail.gmail.com>
From: Peter Wolanin <peter.wolanin@acquia.com>
To: Eran Hammer <eran@hueniverse.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "OAuth@ietf.org" <OAuth@ietf.org>
Subject: [OAUTH-WG] MAC - body hash and response body hash and cache-control headers
Precedence: list

Dear Eran,

I'm still hoping you will consider adding back the MAC spec a
requirement for a body hash covered by the MAC.  I still also feel
that the lack of a hash covered by the MAC that protects the value of
the response and response body makes this proposed spec quite a bit
weaker than it should ideally be.

You mentioned in arguing that there can be operational issues with
verifying the body hash that intermediaries may transform the body.
However, the HTTP 1.1 spec at least includes a header that seems
designed specifically to mitigate at least the concerns about
transformation of the body: Cache-Control: no-transform
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.5

This header should be respected by well-behaved proxies. e.g. see:
http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/#sec-request-no-transform

It would seem that by including this header in the Oauth2 MAC spec for
the request and the response there should not be operational issues
with verifying a hash of the content?

Thanks,

Peter

On Wed, Feb 8, 2012 at 5:59 PM, Eran Hammer <eran@hueniverse.com> wrote:
> New draft:
>
>
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01
>
>
>
> EH
>
>

[OAUTH-WG] MAC - body hash and response body hash… Peter Wolanin