W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

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

From: Adam Barth <ietf@adambarth.com>
Date: Tue, 7 Jun 2011 11:30:12 -0700
Message-ID: <BANLkTimNNwqs2VKM67V9NcBUV1ztvrqe3Q@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, Eran Hammer-Lahav <eran@hueniverse.com>, apps-discuss@ietf.org, Ben Adida <ben@adida.net>, http-state@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, OAuth WG <oauth@ietf.org>
On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams <nico@cryptonector.com> wrote:
> On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>> Nico,
>> Sorry for coming into this so late, but I just saw this message.
>> I don't have all of the background, but when I saw this message header and
>> some of the dialog, it seems there is a desire to provide some level of
>> authentication to requests and/or responses between the clients and servers.
>> Gonzalo and I worked on this:
>> https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04
>> This may not be entirely complete, but the idea was to allow a client and
>> server to establish an association so that requests and responses could be
>> authenticated.  Is this something along the lines of what you are
>> discussing, or is this an entirely different application?
> I'm completely on-board with session state[*].  My comments were
> particularly in regards to threat models.  I believe that
> eavesdroppers and active attackers both need to be considered,
> particularly as we have so many open wifi networks.

Sorry.  We can't address active attackers using this mechanism.  If
you need protection from active attackers, please use TLS.

> To me the simplest way to address the Internet threat model is to
> always use TLS (except, maybe, for images and such elements that have
> little or no security value, though one must be careful when making
> that determination) and to use channel binding.  See the I-D
> referenced below.

Indeed.  This mechanism is for folks who cannot or will not deploy TLS.

Received on Tuesday, 7 June 2011 18:31:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC