- From: Adam Barth <ietf@adambarth.com>
- Date: Tue, 7 Jun 2011 14:24:10 -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 2:17 PM, Nico Williams <nico@cryptonector.com> wrote: > On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth <ietf@adambarth.com> wrote: >> On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams <nico@cryptonector.com> wrote: >>> 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. > > I've already said as much now several times. However, I want channel > binding to TLS too. I'm not sure that's appropriate for this mechanism. What problem does channel binding solve? Adam >>> 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. > > It has value outside TLS as well. Particularly if you're using an > authentication mechanism that can provide mutual authentication (which > OAuth doesn't do today, but I hear there's work in progress to add > mutual auth to it). And then you realize that you might want to do > something similar with other non-OAuth authentication methods, thus > the urge to generalize. > > Nico > -- >
Received on Tuesday, 7 June 2011 21:25:13 UTC