Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme

Nico Williams <> Tue, 10 May 2011 06:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D570E06C7; Mon, 9 May 2011 23:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.09
X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yv82-PiG1ARA; Mon, 9 May 2011 23:45:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E15BFE067E; Mon, 9 May 2011 23:45:31 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 7064642806E; Mon, 9 May 2011 23:45:31 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s=; b=KblccKOWG9KOEOpu/sJpFTp8sdq8xV/MLunfQPZ3XFp5 ifSD+m2NIcIJR4TWZhyzVvsZwy5hB/O5BmXXaJ0qqoeQarIiZBLc1g9O9ypGBgJI 5QPe/aVa5jnksqMUxLhBoudg91DPD7v1fjt0jTbkRIGzhtx0I3ip319ajE+/PgU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=pFQ1Qs9KLnhRa4o9oIZAoia7MAA=; b=LvPijMPsnMR /atmKIVQP5/S3PCOmEHi+Kra5tGIyxW7Jgemk+UkGtF4I4zYqMn20t0PH3b2tID2 +di4an4EpZjgk5ir5i5loETRQJ7AlvW9nz0KOAKvS+9HDfIK9yxEGNjZcCTPbkaH ure2qtsIyI883dx5FLTQhE/07Ih+8Mcs=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 37CAC428014; Mon, 9 May 2011 23:45:31 -0700 (PDT)
Received: by vws12 with SMTP id 12so370804vws.31 for <multiple recipients>; Mon, 09 May 2011 23:45:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id cv1mr771174vdc.277.1305009930450; Mon, 09 May 2011 23:45:30 -0700 (PDT)
Received: by with HTTP; Mon, 9 May 2011 23:45:30 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <> <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Tue, 10 May 2011 01:45:30 -0500
Message-ID: <>
From: Nico Williams <>
To: Eran Hammer-Lahav <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc:, Apps Discuss <>
Subject: Re: [apps-discuss] [saag] Fwd: 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: Tue, 10 May 2011 06:45:32 -0000

On Mon, May 9, 2011 at 3:29 PM, Eran Hammer-Lahav <> wrote:
>> Regarding the question of when to include a hash of the body in the
>> normalized request string that gets MACed... If one is using TLS, then I
>> suggest adding the TLS channel binding into the MAC input string and drop
>> the body hash.  This will speed up operation, since there's no need to hash
>> the body (think of the performance impact of hashing the request body in an
>> implementation that uses sendfile()!).
> It is still not clear when hashing the body is really important, and if this should be just an optional feature or something that is required. If it is optional, it is not clear how the server should indicate to the client that it is required for any particular protected resource. We're still debating that and waiting for some deployment experience to guide us.

See below.

>> I don't see the point of attempting to provide only partial integrity protection
>> (e.g., the draft doesn't say to include ever request header into the MAC
>> input) if there's no TLS.  In fact, I don't see the point of not using TLS, but if
>> TLS avoidance is desired then all of the request (minus the MAC) and
>> response should be covered by the MAC.
> The point is to be practical given the target audience and use cases we have for this: web developers.

Surely not.  Surely the point is to make some attack more difficult.
Yes, surely it's nice to make it easy for developers to use it, but
that's a secondary issue.  The primary issue, what I'm not getting
from the I-D, is what you're trying to protect against.

"What is your threat model?"