Re: Web Keys and HTTP Signatures

Amos Jeffries <> Thu, 18 April 2013 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1290F21F89A5 for <>; Thu, 18 Apr 2013 06:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kJ3F1KUJHcOV for <>; Thu, 18 Apr 2013 06:57:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8482221F8D6A for <>; Thu, 18 Apr 2013 06:57:12 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1USpJt-00057R-FX for; Thu, 18 Apr 2013 13:56:13 +0000
Resent-Date: Thu, 18 Apr 2013 13:56:13 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USpJq-00056d-Ex for; Thu, 18 Apr 2013 13:56:10 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1USpJp-0001Y7-3v for; Thu, 18 Apr 2013 13:56:10 +0000
Received: from [] ( []) by (Postfix) with ESMTP id AEC16E711D for <>; Fri, 19 Apr 2013 01:55:44 +1200 (NZST)
Message-ID: <>
Date: Fri, 19 Apr 2013 01:55:41 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.449, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1USpJp-0001Y7-3v a58bb0197587ef4bfcdb3c68d5b2ab6f
Subject: Re: Web Keys and HTTP Signatures
Archived-At: <>
X-Mailing-List: <> archive/latest/17332
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 19/04/2013 1:42 a.m., Manu Sporny wrote:
> On 04/17/2013 08:00 PM, Martin Thomson wrote:
>> Yeah, that's a pretty bad.  Switching two date-formatted headers
>> might be a simple thing to gain advantage on.  (Last-Modified and
>> Date, might work to poison a cache with old content if the cache
>> isn't rigorous about checking Date).  It seems like a simple fix
>> would be to include the list of headers under the signature as the
>> first item.
> Carsten, James, Martin - good catch, thanks. We had assumed that the
> implementation included the headers names as well as the values in the
> data being digitally signed. As Dave Lehn pointed out, this is a work in
> progress, but we wanted to get something out as sooner than later.
> The attack is only possible if a message is passed over a non-secure
> channel, right? That is, the spec is clear about passing all messages
> over HTTPS. Granted, that's not an excuse for the approach taken and it
> should be fixed, but the attack is only possible if messages are sent
> over an insecure channel, correct?

We had this argument out in the Bearer auth discussions. HTTPS is just 
one layer of security, it can (and routinely is) broken into by 
transparent proxies.

Your auth scheme needs to be as self-contained as possible and take 
advantage of every little bit of security that it can do without relying 
on external layers such as the SSL/TLS layer. It is better to be 
doubly-strong when HTTPS works than to depend on it alone break at the 
first sign of trouble.

IMO signed message schemes like this stand a far better chance of being 
rolled out if they work on plain-HTTP. There are a number of web 
applications and service which require security without the sledgehammer 
and limitations of TLS.