Re: [apps-discuss] HTTP MAC Authentication Scheme

Mark Nottingham <> Thu, 02 June 2011 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3002E0758; Wed, 1 Jun 2011 17:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.11
X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[AWL=-2.511, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zrE3nCJNmr6D; Wed, 1 Jun 2011 17:15:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2A76EE06EB; Wed, 1 Jun 2011 17:15:47 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5BC68509DB; Wed, 1 Jun 2011 20:15:40 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham <>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 2 Jun 2011 10:15:37 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <>
X-Mailer: Apple Mail (2.1084)
Cc: "" <>, Ben Adida <>, "'Adam Barth \(\)'" <>, "" <>, HTTP Working Group <>, OAuth WG <>
Subject: Re: [apps-discuss] 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: Thu, 02 Jun 2011 00:15:48 -0000

On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote:

> This was suggested before, but are there really attack vectors for this?

If not having a current, working attack to demonstrate is a valid way to shrug off a security concern, that's great; it'll be a useful approach to many of the discussions I have. :)

> The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.).

The media type is the important part, and it's much more constrained.

> I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing).

That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing.


Mark Nottingham