Re: Additional use cases

On 5/7/13 3:00 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Tue, May 7, 2013 at 1:35 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:
Ryan
I agree. I agree that every deployment comes with its own risks, and people
come up with ways to mitigate them.
In the Web Crypto case, it looks like the (strong) recommendations we make
for deployments generating signatures are

store keys with PIN (no way to automatically load them)
Instruct your users to enter PIN only on sites using TLS with (EV) validated
certificates


Thanks,
Seetharama


I'm not sure how you reach those conclusions. It seems like it would
be useful for Arun's documentation to explain the rationale.

The first assumption is we're talking about origin-bound keys - eg:
what the core spec declares, not about any other aspect or future
work. If you're thinking about smart cards or other keys, then our
assumptions about the security model are entirely different, and thus
an entirely different set of assumptions need to documented before we
can reasonably discuss the use case that explains the assumptions.

With such per-origin keys, why can the origin not prompt (through its
web UI under the web applications control) a "PIN" prompt. What
assurances do you expect to realize if the "PIN prompt" is implemented
in browser-chrome versus in the web page.

How does this compare with middleware prompting - which itself is "as
insecure" as having the webpage prompt.

Also, note again, keys are per-*origin*. That means the HTTP version
of a site can never access the HTTPS keys - and vice versa.

That is my point – use HTTPS. Origin protection in case of HTTP does not mean anything.

Now, coming to PINs, I am not suggesting that it be integral part of the API – and I agree that it could be promoted by the web application itself (and JS uses to decrypt to get the original key, for example). What I am saying is that in general, particularly for non-repudiation, we do not want implementations to store keys without PIN/password protection.




As for EV, that provides no added security value in practice, so it's
not worth mentioning.

On 5/7/13 11:48 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Tue, May 7, 2013 at 8:14 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:

With the ownership of the key based on SOP that is not cognizant of
tampering (as of now), I am afraid that any discussion of signatures will be
futile, they cannot be used for non-repudiation, at the end of the day.

http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0247.html


I don't see why you equate the discussion of ownership at all with
tampering/proof.

Further, I don't know if your claims are entirely justified to say
"They cannot be used for non-repudiation".

A quick example of the many attack vectors that exist in today's
applications - and yet are still somehow acceptable for
non-repudiation:
1) Native executables may or may not be code-signed.
2) There is no way for native executables to verify that they have
been properly code-signed with no malicious code injected. If
malicious code was injected, it would just lie.
3) There is no way for smart cards to know whether or not the calling
application is "legitimate". For example, it's not at all uncommon to
see malware hijack smart cards (eg: see Sykipot)

There are two realities here - the technical reality and the political
reality. The political reality of non-repudiation likes to believe
that today's solutions are acceptable - even though the technical
reality is flawed.

If these arguments all sound familiar, well, it's because I said the
exact same thing in September - see the thread
http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0156.html
(and don't forget Anders' comments on public-webcrypto-comments at
http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Sep/0010.html
)

This disconnect has nothing to do with the ownership model of the key
- either you accept some technical realities or not.

For example, in the native code, you have no assurances that hostile
code/malware is not running on the users machine. A PIN or password do
nothing to mitigate this threat. If you accept those signatures, then
WebCrypto should be the same. Your "code signature" is handled via TLS
- and your signature verification can be bolstered via means such as
pinning. Either you trust that code or you don't - no different (nor
more flawed) than native.

I'm sympathetic for those who want "more" assurances - but I want to
make sure it's recognized how fundamentally flawed the argument is
when compared to the already deployed, politically accepted reality of
general purpose computing. If we're going to try and improve things,
we must set reasonable expectations about what the real threats are
and what the benefits are.

If the only security guarantees for the Web API can be realized when
on a fully restricted, user-hostile machine (eg: not the general
purpose machine that the browser vendors represented here develop
for), then I'm more inclined to suggest that it belongs elsewhere -
such as SysApps or somewhere else - because it doesn't reflect a
general pattern for an open Web.