Re: A working multi-domain WebCrypto - TLS client cert auth

On Fri, Aug 24, 2012 at 10:54 AM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> On 2012-08-24 19:38, Ryan Sleevi wrote:
>> On Fri, Aug 24, 2012 at 5:04 AM, Anders Rundgren
>> <anders.rundgren@telia.com> wrote:
>>> Before taking on any major work to solve the multi-domain issue, I think it is worthwhile studying one existing already implemented and relatively widely used such solution.
>>>
>>> Is there anything fundamentally wrong with this solution except that it isn't a JS API?  I could imagine an X.509 client-certificate extension that would restrict the list of possible relying parties to what fits the use-case.
>>>
>>> A demo-server that asks for you to select one from *all* of your certificates:
>>> https://www.apache-ssl.org/cgi/cert-export
>>>
>>> BTW, multi-domain symmetric keys doesn't look like a terribly useful combination.
>>>
>>> Anders
>>>
>>
>> Hi Anders,
>>
>> Thanks for posting this. I actually think the scenario you describe
>> represents a single origin access model, which may be why there is
>> some confusion around single/multi-origin.
>
> Hi Ryan,
>
> There may indeed be confusion but what *I* consider multi-domain is a key that
> can (by design) be consumed by multiple and potentially independent parties.

But in the TLS client auth, the key is not being consumed.

It is a signature generated by the key, mediated by some trusted
application on the user's local machine.

In a multi-origin model as proposed, the key itself, not a specific
signature, are being granted to the application.

Using SSL/TLS as the continued example, what's being discussed would
be an SSL/TLS extension that, when client certs are used, would allow
the peer/server to instruct the client to sign any number of arbitrary
messages.

To put it differently, any use case where a single application
performs signing of specific messages, for consumption by arbitrary
parties, is actually what I would call a "single origin" use case.
Whether this is a user agent signing TLS messages, a browser plugin
that signs specifically formed "transaction" messages for some
proprietary payment scheme (the Korean/Asian use case, AIUI), or an
application that loads specifically formated documents, displays them
to the user, and computes an XML signature over it (the Nordic use
case, AIUI), I think it's in reality a single origin. In each of
these, access to the keying material is mediated by a well known
application, and the 'consumers' (TLS servers, plugin embedders,
document services) simply provide structured messages of
things-to-be-signed, rather than computing the signatures directly.

The easiest way for people not familiar with the web security model,
but familiar with cryptography APIs, to map these concepts, is to
mentally think of an "origin" as "a single application". Do you
require every application to be updated to support your special
messaging format? Or do you use (plugins, custom applications) to vend
(signatures, encrypted messages) from some form of structured data?

I suspect that for many of these use cases, the desire is not to
expose the key itself, nor to require every web application be updated
to support whatever custom/proprietary message encoding scheme du
jour, but to instead have a common framework for which, instead of
plugins, these government schemes can be replaced by "web
applications" that are written in a consistent language (JavaScript)
and can run on multiple user agents on multiple device types, all of
which behave exactly the same. This is, I believe, an advantage over
the current solutions (ActiveX, native code, Java with native code)

>
> That is what I (rightly or wrongly) think is the Korean use-case which
> actually is quite significant.
>
> It is still beyond my understanding how you can combine this with an API
> like WebCrypto.
>
> Regards,
> Anders


>
>>
>> In the TLS client auth scenario, only one application (web or native)
>> actually has access to your keying material - the user agent or
>> application communicating with the (myriad) TLS servers. For each
>> origin you're performing TLS negotiation with, they only receive a
>> signed statement. This statement (the ClientCertificateVerify) is
>> constructed through combining material from the server with material
>> that it cannot control (the client's hello and random), thus ensuring
>> that the server cannot spoof or relay messages.
>>
>> Under such a scenario, the "risk" is of native applications being able
>> to run on the client machine. A native application that is granted
>> unfettered access to the key (much like the user agent is) would be
>> allowed to sign any message. One class of applications that seek to do
>> this are 'malware' applications, which attempt to act as TLS MITM
>> while still preserving client auth.
>>
>> If we apply a literal translation of these concepts, then we arrive at
>> a situation where a single origin has access to the actual key, but it
>> is permitted to mediate messages to other origins (eg: the
>> ClientCertificateVerify), based on their requests. In the Web model,
>> there are many ways to deliver such requests - iframes, postMessage,
>> intents are just a few examples - but the overall security is
>> preserved only when a single origin is permitted to access the key.
>>
>> If you permit multiple origins, then any of those origins becomes a
>> potential target for compromise, and such attacks on Origin-B can be
>> then leveraged into MITM attacks on Origin-A.
>>
>> Because of this, I think it is important to preserve same origin
>> policy restrictions, as discussed during and within the charter, and
>> look at ways for applications to expose mediated/'safe' ways for other
>> origins to request they sign or encrypt some message.
>>
>> Does this help?
>>
>>
>

Received on Friday, 24 August 2012 18:15:02 UTC