Re: [http-auth] [saag] re-call for IETF http-auth BoF

[Nico Williams <[e-mail]>]

On Mon, Jun 6, 2011 at 9:16 PM, Marsh Ray <[e-mail]> wrote:
> On 06/06/2011 07:20 PM, Stephen Farrell wrote:
>> On 06/06/11 23:33, Marsh Ray wrote:
>>> Don't worry about it, they're not going to work even that well.
>>
>> Just trying to understand this. Why won't what work well?
>
> Well you can probably make the math more efficient. You could certainly
> improve on the crypto handling ability of a language like Javascript which
> has neither secure memory overwrite nor constant time comparison operations.
>
> But is there any plausible attack scenario where crypto in the web page adds
> meaningful security?
>
> I don't think so. Either:
>
> A. TLS is correctly securing the connection, in which case you could just as
> easily ship the plaintext to the server, or
>
> B. TLS is not present or ineffective, in which case it's the attacker who
> controls what script is running in the page to such an extent that it's not
> even worth discussing distinctions in the degree of the compromise. I.e.,
> pwned.

Exactly.  There is, however, a third possibility: code signing.  That
is, we could have a script (and, for that matter, HTML document)
signing mechanism, then browsers could trust signed code even if not
delivered over TLS.

Note though: I'm not advocating code signing.  On the web code changes
much too often, for one.  But the biggest problem is that you'd have
to make sure that there's no leakage of untrusted bits into a page
such that trusted code could be subverted to perform actions that it
should not.  Web pages nowadays consist of a great many objects that
have to be fethced via HTTP -- this means that code signature
verification for all of them would be akin to using HTTP/1.0 (i.e.,
not pipelining) and TLS w/o session resumption, in that an asymmetric
crypto operation would be required for each object.  That's a lot of
asymmetric crypto!!

In short, I don't think code signing on the web is a terribly
practical idea, except, maybe, for generally stable libraries.

There's also a fourth possibility: that crypto APIs will be used to
access PKCS#11-like tokens (soft or hardware).  But the browser, and
therefore the user, will never know what a script means to do when
using a given key, which means that we couldn't gain much security
from this fourth possibility.

We're left with the two options that Marsh stated, and which more than
one of us explained at the W3C workshop (these are obvious problems),
which means that JS crypto will add no security.

Nico
--