Re: [perpass] perens-perpass-appropriate-response-01

[Stephen Farrell <[e-mail]>]

Bruce,

On 12/07/2013 07:29 AM, Bruce Perens wrote:
> On 12/06/2013 01:20 PM, Nicholas Weaver wrote:
>> If the attacker can see your fetches he can execute a
>> man-on-the-side attack through packet injection.
> This is the first one I've seen that is actually compelling.

I agree that Nicholas' posting is compelling. It really is.

I also agree that a bunch of the non-technical analogy-driven
stuff is not at all compelling.

But one compelling argument is enough really.

> But it's an . authentication problem rather than a confidentiality
> one.

I don't think so. The lack of confidentiality lets the
adversary win the race unless you assume 100% coverage
of authenticated JS and 100% validation of that and that
there are no diginotar like entities involved in the
currently non-existent JS authentication infrastructure.

Even ignoring the race condition, it'd only be reasonable
to treat this as an authentication-only problem if there was
a solution for the JS authentication problem.

Today, there's no such solution for how to load JS with
integrity but without TLS after an https:// "landing page"
load. I've thought about ways to do it with RFC 6920, but
so far without finding a way that could scale or would be
likely to get adopted - apparently the JS code gets
updated too often for a 6920 based approach to help very
much.

So, while authenticated-JS is also a fine problem on which
to work, today we have tooling for addressing the problem
via ubiquitous TLS but we do not have the kind of tooling
that would be needed for a solution that does not provide
confidentiality.

Even if we only did opportunistic encryption then an
observatory could spot a pervasive attack against that, or
against that for Air France to use the example cited. (Air
France might be motivated to want such an observatory to
exist for example.)

Separately, if one considers the long-tail bits of JS code
loaded from the long-tail set of web sites then again there
is some benefit in confidentiality since without that the
adversary can pervasively find the vulnerable code and sites
from those. The "long-tail" here is relevant because we
should assume the adversary knows the vulnerabilities for the
top-10^N sites and JS packages. I think any IETF approach
to this kind of thing should not give a high preference to
the top-10^N anything really, which again argues for doing
this based on TLS or similar I think.

So what I see is a compelling problem-statement, and an
existing set of tools that can address that if more widely
deployed, and where confidentiality is in reality an inherent
part of doing that.

Cheers,
S.