Re: [foaf-protocols] New attack plucks secrets from HTTPS-protected pages

On 8/4/13 5:34 PM, Melvin Carvalho wrote:
>
>
>
> On 4 August 2013 22:54, Peter Williams <home_pw@msn.com 
> <mailto:home_pw@msn.com>> wrote:
>
>     one of the things that came "before its time" is making a come
>     back. One has to play the "factoring" game "sensibly" - much as
>     one has to allow security committees to be stacked with
>     agendized-folks with money (that pays for core research, too).
>     If you look in dotNet, there is a particular ws-trust/ws-security
>     binding. Its compatible with java, etc (circa 5 years ago, when
>     Java security mattered.) More importantly, its compatible with
>     apache libs, these days. In short, the saml process of delivering
>     a per-recipient encrypted proof key (within the signed XML) was
>     leveraged so that it delivered a client's EPHEMERAL rsa key. Any
>     client proxy (and you can have n of those, and being generated for
>     a given service instance exposing service&policy-metadata) can
>     maintain 1000 of these in its RSA security token cache; before
>     keys overwrite cache slots. Typically, the client signs web
>     service call headers (timestamp, and address) using the RSA key,
>     rather than signing with hmac similarly.
>     So, if you are worried about your 512 bit RSA being factored in
>     500 hours, (or 50, or 5)  why not give it a life time of 500mS,
>     and just use 1000 of them? There is built in probability drive in
>     every CPU...
>
>
> Ephemeral keys are a nice option.  But long lived keys also have 
> advantages:
>
> 1. You can build up a reputation for each key

You can't have it both ways!


> 2. You can build cachable relationships between your identity and your key

See comment above.

> 3. You can store virtual currency against a key, and transfer or prove 
> ownership by signing

See comment above.

> 4. You can spend time generating a key via proof of work algorithm to 
> show you're not a sock puppet

See comment above.
>
> So there's a trade off between security and key management.


The moment you think about a single key, you've stopped thinking about a 
composite key. Once you stop thinking about a composite key, forget the 
entire pursuit.

Remember, eons ago, I said this whole thing was about a composite key + 
logic. Modulo Peter, I got a lot of strange looks, and so I just stopped 
talking about composite keys, mirrored claims, and a semantically driven 
web of trust.

We can't have it both ways. The game has to be "deceptively simple" but 
never "simply simple".

Convenience is always the enemy of solid pursuits of complex issues such 
as privacy.

To conclude, "one key" doesn't work. A composite key has to be the 
starting point. In WebID based trust thinking you have a composite 
comprised of:

1. private key
2. public key
3. HTTP URI .

Unlike a SQL DBMS composite key, this one is enhanced by the fact that 
HTTP URIs are denoting Agents which introduces DNS which introduces the 
Authority to persist claims. Then, again unlike a SQL RDBMS we have 
logic discernible from the Trust Web that starts with the Profile Graph 
and its machine-comprehensible entity relationship semantics. Finally, 
we have the keypair proof from asymmetric keys (the public and private 
key pair) .

When I construct a data access policy around your WebID it isn't around 
a single key. It's actually around a composite key re. the WebID+TLS 
protocol. In short, that would be the case whenever the mirroring of 
claims between a locally stored certificate and some publicly accessible 
profile document drives the authentication protocol.

There isn't a single secret. There isn't a single key. But none of that 
stops the use of a WebID as a canonical identifier for an Agent in a 
manner that scales to the Web and the Internet.

Kingsley


>     *From:* Melvin Carvalho
>     *Sent:* Sunday, August 4, 2013 10:14 AM
>     *To:* Peter Williams
>     *Cc:* public-webid, foaf-protocols@lists.foaf-project.org
>     <mailto:foaf-protocols@lists.foaf-project.org>
>
>
>
>     On 4 August 2013 17:16, Peter Williams <home_pw@msn.com
>     <mailto:home_pw@msn.com>> wrote:
>
>         nothing new.
>         so use compression that is BUILT IN to the SSL process. IT is
>         properly tuned. It properly uses the record layer so
>         record-layer AND security handshake boundaries
>         are "application aware". It does make SSL more of an internet
>         (i.e. layer 4 peer entity layer) concept, than a webby layer
>         7 "hypermedia concept", though.
>         But, note that compression and SSL *was* patented (and
>         continuations may still be). It was proactively-patented for
>         national security reasons; both good and bad. The good one was
>         to stop folks doing it completely wrong (this was at a time
>         when VeriSign required SSL vendors to undergo a basic software
>         audit to be allowed to embed root keys, a governance technique
>         designed to "stop folks being stupid about basic comsec that
>         would undermine the value of the [VISA] brand attached to
>         certs"). The bad one was the usual CI caveat reason - minimize
>         the distribution of knowhow about military cryptananalysis
>         methods. We are all still thinking 1980s, even in 1994, one
>         should recall.
>         A webid IDP is perfectly proper place to apply better knowhow,
>         as is ws-trust STS IDP that leverages clients certs at layer 4
>         to authorize SAML/JWT token minting. These are proper places
>         to apply strong crypto knowhow, speaking in terms of social
>         politics.
>         Sent from Windows Mail
>
>
>     Here's a great presentation about cracking RSA.  Perhaps we will
>     need bigger keys or to switch to ECC sooner than we thought ...
>
>     http://www.slideshare.net/astamos/bh-slides
>
>         *From:* Melvin Carvalho
>         *Sent:* Sunday, August 4, 2013 7:10 AM
>         *To:* public-webid, foaf-protocols@lists.foaf-project.org
>         <mailto:foaf-protocols@lists.foaf-project.org>
>         http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/
>
>
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen