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

On Tue, Jun 7, 2011 at 6:41 PM, Tim <tim-projects@sentinelchicken.org> 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?

Nico
--

Received on Wednesday, 8 June 2011 00:08:09 UTC