W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: New "Goals" (use-cases) - Is your use-case there, accurately described?

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 09 Dec 2011 19:40:18 +0000
Message-ID: <4EE26422.4080605@cs.tcd.ie>
To: David Dahl <ddahl@mozilla.com>
CC: Harry Halpin <hhalpin@w3.org>, public-identity@w3.org

On 12/09/2011 06:03 PM, David Dahl wrote:
 > ----- Original Message -----
 >> From: "Stephen Farrell"<stephen.farrell@cs.tcd.ie>
 >> To: "David Dahl"<ddahl@mozilla.com>
 >> Cc: "Harry Halpin"<hhalpin@w3.org>, public-identity@w3.org
 >> Sent: Friday, December 9, 2011 10:53:38 AM
 >> Subject: Re: New "Goals" (use-cases) - Is your use-case there, 
accurately described?
 >> Hi David,
 >> On 12/09/2011 03:36 PM, David Dahl wrote:
 >>> TLS provides for transport security, this API is about fully
 >>> client-based crypto.
 >> That's a false dichotomy.
 > Not really,

It is I'm afraid. But whatever.

 > this is the argument about how "we have SSL", so "there are no 
worries, man" - am I correct? That is how I have interpreted what you said.

Your interpretation is incorrect. (And surprising to be honest.)

There are many problems in the world. Some affect TLS, probably
more affect x.509/rfc5280. So things like DANE, cert pinning,
bare keys in TLS and OBC (if done right, I'm not that keen on
the current proposal:-) can all help. So can the API being
discussed here.

But any "sky is falling" claims are, as always, exaggeration.
As would be any claim that there are no problems.

 >>> We are seeing commercially available SSL MitM devices available for
 >>> sale, and CAs are being broken into on a monthly (it seems) basis,
 >>> with revelations of certificates being issued to unknown entities
 >>> that allow these thieves to masquerade as Google.com and other
 >>> domains. Also, unless I am missing something, TLS does not allow you
 >>> to prevent the server/third parties from capturing plain-text
 >>> content.
 >> And you expect a client-side API to fix all that? You must
 >> be very... optimistic:-)
 > Now you are putting words in my mouth.

Sorry if that appears to be the case.

 > I am talking about layers of security here, and increasing user 
control in the DOM. I am not talking about fixing the CA system.

That was not clear from your mail.

 >>> Properly used -
 >> Hmm.
 >>> and it is being designed to make it hard to use it wrong,
 >> I don't know how to do that. I do know ways to badly design
 >> crypto APIs, but I don't know how to design one to make it
 >> hard for a developer to screw up. I guess its a useful design
 >> goal for the API developers though, even if not that much
 >> can really be done.
 > Your only inputs to this API are a typed array of data to encrypt and 
a TypedArray representing a public key. That's pretty hard to get wrong.

Where'd the key come from? Does the decryptor assume
that success implies origin authentication? Does
this call add randomness/padding internally or
not? Is the plaintext guessable in any case?

Is it a key handle or key bits? What if the plaintext
is longer than appropriate for the key and you need
some mode of operation or symmetric cipher? How long
does it take to do the operation? (the same or varying
amounts of time?)

There are things to get wrong both in the calling
and called code.

But other APIs offer more potential for doing the
wrong thing.

Arguing aside, it would be good to think about ways in which
developers could do the wrong thing with the API as part of
the design process.

 >>> this API will has the potential to help a developer build more
 >>> secure messaging tools.
 >> I'd love to see some evidence for that claim about "more secure"
 >> or at least some analysis to back up the argument. I've seen
 >> neither and I don't think its at all useful to oversell things
 >> like this.
 >>> Many "secure" messaging tools are being built right now in an
 >>> insecure manner. Web devs are rolling their own crypto and using
 >>> libraries that expose key material to content JS - not to mention
 >>> the slow performance issues. Web devs are already way ahead of
 >>> browser makers here, to the detriment of endusers. We are playing
 >>> catch-up, and we have the ability to safely expose proven crypto to
 >>> the DOM.
 >> There we do agree. And it seems to me that the corollary of
 >> that argument is: the fewer API calls they have to use, the
 >> more everyone gets to use better tested stuff (i.e. encourage
 >> use of TLS + key extraction to flog my own favourite dying
 >> horse).
 > How will TLS + key extraction make this API better or more usable to 
you? More details would help me grasp your argument.

Better in the sense that it'll work for a bunch of use
cases and won't involve the developer in inventing any
security protocol except for the application one. All
key management would be inside TLS. And hence is known,
warts and all, which is still better than most developers
will manage.

I don't claim this will work for all use cases. (Accelerators
in particular on the server side would be a problem.)

But I reckon it represents the least amount of code for
the client side to get confidentiality and integrity for
application layer data between that client and the
server-side TLS endpoint.


 > Regards,
 > David
Received on Friday, 9 December 2011 19:40:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:09:07 UTC