Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme

Tim <> Mon, 13 June 2011 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 042E621F84E6 for <>; Mon, 13 Jun 2011 08:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.401
X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N1u59Cblecda for <>; Mon, 13 Jun 2011 08:28:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2020A21F84DE for <>; Mon, 13 Jun 2011 08:28:37 -0700 (PDT)
Received: (qmail 24165 invoked from network); 13 Jun 2011 15:28:33 -0000
Received: from unknown (HELO ( by with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Jun 2011 15:28:33 -0000
Received: (qmail 14338 invoked from network); 13 Jun 2011 15:29:28 -0000
Received: from ( by with SMTP; 13 Jun 2011 15:29:28 -0000
Received: (nullmailer pid 337 invoked by uid 1000); Mon, 13 Jun 2011 15:28:32 -0000
Date: Mon, 13 Jun 2011 08:28:32 -0700
From: Tim <>
To: Eran Hammer-Lahav <>
Message-ID: <>
References: <09c801cc24c2$a05bae00$e1130a00$> <> <00f101cc255e$2d426020$87c72060$> <> <015801cc25ab$063a2150$12ae63f0$> <> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <> <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E774395@P3PW5EX1MB01.EX1.SECURESERVER.NET>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: OAuth WG <>, "" <>
Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jun 2011 15:28:39 -0000

Hi Eran,

> ... Until everyone deploys TLS, including such non-TLS bits in a TLS
> page cause the browser to show a broken TLS state in the address bar.
> For most web users, that's more of a red flag (valid TLS but with some
> resources loaded without TLS) than no TLS at all. 

And in fact, in any modern browser, this situation is rightfully
called out as an insecure deployment.  Many one of those non-TLS
resources you refer to could be modified by an attacker to inject
malicious script and therefore hijack sessions.

> The reality is that
> it is really hard to deploy TLS applications today without having
> issues with at least one vendor (especially when that vendor is an ad
> network you rely on for your profits).

Agreed.  It is a typical "no one can do it because no one else is
doing it" situation.

> Yes, adding MAC to cookies without TLS
> does not provide anywhere near the protection of TLS, but it is better
> than nothing, when TLS is not available.

To Nico's point, I'm not entirely sure about that.  If something like
MAC caught on, where would people deploy it?  They deploy it to
protect credentials over non-TLS connections, right?  So it might be
used as yet another excuse not to use TLS, even though it doesn't
provide the kind of protection that most users would expect.

In modern browsers, MAC would do nothing to stop someone from
injecting script into a response which initiates arbitrary requests on
behalf of a user.  A browser would have no idea that the script was
malicious, so it would happily sign requests as if they were
user-initiated.  To the point: session hijacking isn't just about
stealing and reusing a session token.

I see no problem trying to provide something to help protect user
credentials through hard-to-crack hashes and the like, since those are
often used in more than one place, but I see no point in trying to
provide one-way integrity protection.