Re: Web Keys and HTTP Signatures

Daniel Friesen <daniel@nadir-seen-fire.com> Thu, 18 April 2013 14:03 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDDF21F855A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Apr 2013 07:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFdbPU5guCRd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Apr 2013 07:03:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8F21F85D4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 18 Apr 2013 07:03:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1USpPx-0002PI-2O for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Apr 2013 14:02:29 +0000
Resent-Date: Thu, 18 Apr 2013 14:02:29 +0000
Resent-Message-Id: <E1USpPx-0002PI-2O@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <daniel@nadir-seen-fire.com>) id 1USpPq-0002N0-0x for ietf-http-wg@listhub.w3.org; Thu, 18 Apr 2013 14:02:22 +0000
Received: from mail-pa0-f45.google.com ([209.85.220.45]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <daniel@nadir-seen-fire.com>) id 1USpPl-0002Nw-Ey for ietf-http-wg@w3.org; Thu, 18 Apr 2013 14:02:21 +0000
Received: by mail-pa0-f45.google.com with SMTP id kl13so1619014pab.32 for <ietf-http-wg@w3.org>; Thu, 18 Apr 2013 07:01:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nadir-seen-fire.com; s=google; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x4D1up71nsgzpNIsiQOSf060MmrhkpXe/EfxgewY+fg=; b=d4S1vTQMgYE0TPSPc8W7Kk8sO//EFEwGsGBU9BZfIUmz5XCWdS3ZD3o19usZTV2HKq tgkeJ+54LOqIaCfJqaAGgq6q9nGq79e3tIAjYht9FnCr0Q/5+3p1TrjW2rh9UZF42cvK cvJjC9udXU9UUjyJ1+f1+pReEOtD8OjrB2/Jo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=x4D1up71nsgzpNIsiQOSf060MmrhkpXe/EfxgewY+fg=; b=QXljKRUgJJyGCD3BoKEw7Vps5scv+3bIJ7WsV/gwJWUQuReWNAaKqdVy1DcFya2VM8 Di3tutkJIxBDYMxyqscnHePm5Up9gWGtK/CgWL6Y7lJdHZ7N2aFcIhWdOv/0TpgOzR6s /N01lcmH4vq4nG3UL6pCAm2gJOTnKR9zDdv2M03gDyuiN3XjwR5zIcB7prR2BfdON2Fm fybKhsgem7nBHnCqXZAjlaWj/SR+EhB6HscyiWWvQT269VnqIE76gugwFpBkYHA+d44Z UK/LgGCGGzoMh7o6wmvMfZv7JpqyXyLALL8sQpW2cYJ3sf+c2mldhvXsPOpelgxf3sl0 22dg==
X-Received: by 10.66.118.201 with SMTP id ko9mr13192757pab.81.1366293711015; Thu, 18 Apr 2013 07:01:51 -0700 (PDT)
Received: from Daniels-MacBook-Air.local (S0106602ad0749b6b.vs.shawcable.net. [70.71.114.219]) by mx.google.com with ESMTPS id wi6sm10008599pbc.22.2013.04.18.07.01.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 07:01:50 -0700 (PDT)
Message-ID: <516FFCCC.6060306@nadir-seen-fire.com>
Date: Thu, 18 Apr 2013 07:01:48 -0700
From: Daniel Friesen <daniel@nadir-seen-fire.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
CC: Martin Thomson <martin.thomson@gmail.com>, "Manger, James H" <James.H.Manger@team.telstra.com>, Carsten Bormann <cabo@tzi.org>, Web Payments CG <public-webpayments@w3.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
References: <516F14E1.5040503@digitalbazaar.com> <9DF0F237-62DC-4E82-A545-B09C6083849B@tzi.org> <CADcbRRN2XWa9QwuaXAoxjMdkcguvQiiGq934RXU=-1ntzGpWNQ@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1150C90E93E@WSMSG3153V.srv.dir.telstra.com> <CABkgnnXoY3iOH7M=A5hCo+eTnDiPODvgmdnDay0AKUo4PsuoMg@mail.gmail.com> <516FF833.1000401@digitalbazaar.com>
In-Reply-To: <516FF833.1000401@digitalbazaar.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm1oAeQlGMmCMwQ9HOs17UADjeGLIen3tqscM0epUUfcad2PyeFelbz/93cKHyqyRiCd5Bg
Received-SPF: pass client-ip=209.85.220.45; envelope-from=daniel@nadir-seen-fire.com; helo=mail-pa0-f45.google.com
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Hub-Spam-Report: DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1USpPl-0002Nw-Ey 44cf7639c800730798e7da1e55eefad6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Web Keys and HTTP Signatures
Archived-At: <http://www.w3.org/mid/516FFCCC.6060306@nadir-seen-fire.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17334
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 13-04-18 6:42 AM, 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?
>
> -- manu
>
You might want to think twice before you consider https implemented in
anything other than a web browser absolutely secure:
http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]