On Fri, Jun 10, 2011 at 2:16 PM, Adam Barth wrote:
> On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams wrote:
>> The fundamental issue is that protecting the cookie alone is not
>> enough. On open wifi networks it's a fair assumption that the
>> difficulty of active at
[Dropped a few lists.]
On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones wrote:
> What issues, specifically. (Messages are all over the place and I don’t
> know exactly what issues you’re raising. Is it with the approach we’re
> proposing or something else?)
The fundamental issue is that protecti
On Wed, Jun 8, 2011 at 5:26 PM, Breno de Medeiros wrote:
> On Tue, Jun 7, 2011 at 17:07, Nico Williams wrote:
>> 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
On Jun 8, 2011 2:09 AM, "Paul E. Jones" wrote:
>
> Nico,
>
> Cookies would still be employed. A cookie would be used to identify the
particular user, for example. However, it's important to make sure that the
cookie provided by the client to the server is not stolen. It's important
to ensure th
On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills wrote:
> It is possible to implement decent security with MAC, it is also possible to
Not as specified. See earlier posts regarding active attacks.
> screw it up. It is far more difficult (impossible?) to implement decent
> security with cookies
On Tue, Jun 7, 2011 at 8:05 PM, Randy Fischer wrote:
> On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wrote:
>> Or am I missing something?
>
> Well, last I tried it under apache, at least, there was a hard limit
> on the length of
> a TLS stream. Since I use HTTP for a sto
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 wo
On Tue, Jun 7, 2011 at 6:00 PM, Ben Adida wrote:
> On 6/7/11 3:57 PM, Nico Williams wrote:
>>
>> Not if the MAC doesn't protect enough of the request _and_ response to
>> prevent active attacks. Unless you don't care about those attacks
>> (which some of y
On Tue, Jun 7, 2011 at 5:43 PM, William J. Mills wrote:
> MAC adds security if the initial secret exchange is secure, and it provides
> a definition for signing payload as part of the request.
Not if the MAC doesn't protect enough of the request _and_ response to
prevent active attacks. Unless y
On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones wrote:
> I fully agree with you that using TLS is usually preferred. That said, we
> encounter situations where there were a large number of client/server
> interactions and the data conveyed is not confidential information in any
> way. Using TLS
On Tue, Jun 7, 2011 at 4:24 PM, Adam Barth wrote:
> I'm not sure that's appropriate for this mechanism. What problem does
> channel binding solve?
CB is not appropriate for OAuth today, no, because OAuth doesn't give
you mutual authentication, which means channel binding can't be done
either (we
On Tue, Jun 7, 2011 at 1:41 PM, Igor Faynberg
wrote:
> Adam Barth wrote:
>> Sorry. We can't address active attackers using this mechanism. If
>> you need protection from active attackers, please use TLS.
>
> Actually, IPsec will work here (with WiFi networks) just as well. It is
Not really. S
On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote:
> On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote:
>> I'm completely on-board with session state[*]. My comments were
>> particularly in regards to threat models. I believe that
>> eavesdroppers and active
On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones 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
> authenticati
On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav wrote:
>> Additional comments:
>>
>> - Using nonces for replay protection is heavy-duty. It is difficult to
>> implement a reliable, secure, high-performance replay cache. (It is easy to
>> implement just a high-performance replay cache: use
>>
Additional comments:
- Using nonces for replay protection is heavy-duty. It is difficult
to implement a reliable, secure, high-performance replay cache. (It
is easy to implement just a high-performance replay cache: use
memcache.)
I recommend an option to use sequence numbers at the server'
16 matches
Mail list logo
