- From: Adam Barth <ietf@adambarth.com>
- Date: Tue, 7 Jun 2011 11:30:12 -0700
- 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. Adam
Received on Tuesday, 7 June 2011 18:31:21 UTC