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

Nico Williams <> Wed, 08 June 2011 00:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD6F211E813F; Tue, 7 Jun 2011 17:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.088
X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cefikWRneL9D; Tue, 7 Jun 2011 17:07:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F202211E80B2; Tue, 7 Jun 2011 17:07:39 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C4C2F67C06D; Tue, 7 Jun 2011 17:07:39 -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=Qp2Tej8sQu6p8GCJ3ViGASnUPPlA230lKv1LANp9H1ID f1b1rdAJuJm56m60LpnKP7fyGKGgHO5FvKLrmt10ji3SjXyVPSEtcZ3TRuihLlXS x5C5eTz1sXes0GCCNaMjQQ6NwCyyx84OpO7WaHUEsFZOX1JCC1cM3TRmU0ugVUo=
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=H6jQsCDKAW1ELuHLEHnpEBnUiNs=; b=T52XUZRkd0e 6GZgKOxowzNbcf3syhQcaBoUm/CwIjYPQV6a32koBZwQI8n+U4rWA01RUayiKU4J RxKyu9La76RjkabYTJYYGxGyfpGHz4aLE0MeFjkptSpa7vqeHnNcIlojkLoz7w9G Q4fMKh2Q/JR5eA70pgr1X+MJgW6p88Ho=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 9FCF067C069; Tue, 7 Jun 2011 17:07:39 -0700 (PDT)
Received: by pzk5 with SMTP id 5so2867pzk.31 for <multiple recipients>; Tue, 07 Jun 2011 17:07:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id e9mr636701pbb.255.1307491659198; Tue, 07 Jun 2011 17:07:39 -0700 (PDT)
Received: by with HTTP; Tue, 7 Jun 2011 17:07:39 -0700 (PDT)
In-Reply-To: <>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <09c801cc24c2$a05bae00$e1130a00$> <> <00f101cc255e$2d426020$87c72060$> <> <> <> <> <> <>
Date: Tue, 7 Jun 2011 19:07:39 -0500
Message-ID: <>
From: Nico Williams <>
To: Tim <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <>, HTTP Working Group <>, "" <>, "" <>
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: Wed, 08 Jun 2011 00:07:40 -0000

On Tue, Jun 7, 2011 at 6:41 PM, Tim <> wrote:
> I have to agree with Nico here.  In almost all cases I assert that, on
> typical modern networks:
>  let P = difficulty of passive attack
>  let M = difficulty of active (man-in-the-middle) attack
> O(P) = O(M)
> .
> This isn't to say the "real world" difficulty of an active attack is
> just as easy, but it is within a constant factor.  If someone has
> published a tool that conducts MitM attacks for the specific protocol
> you're dealing with, the difference in difficulty clearly becomes
> marginal.  Consider the complexity of the attacks implemented by
> sslstrip and yet the relative ease with which you can use it to MitM
> all SSL connections.

Exactly, and very well put.

Active attacks sound harder, and they do actually require more work,
but in many cases that work can be automated, and once automated there
can be no difference in effort required to mount an active attack
versus a passive one.

Do we suppose that this proposal can get past secdir, IESG, and IETF
reviews as-is?  I doubt it.

Here's another issue: some of you are saying that an application using
this extension will be using TLS for some things but not others, which
presumes a TLS session.  Does using TLS _with_ session resumption
_and_ HTTP/1.1 pipelining for all requests really cost that much more
in latency and compute (and electric) power than the proposed
alternative?  I seriously doubt it, and I'd like to see some real
analysis showing that I'm wrong before I'd accept such a rationale for
this sort of proposal.

Or perhaps the motivation relates to accidental leakage of "secure"
cookies in non-secure contexts.  But why not just fix the clients in
that case?