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

On 5 August 2013 00:10, Kingsley Idehen <kidehen@openlinksw.com> wrote:

>  On 8/4/13 5:34 PM, Melvin Carvalho wrote:
>
>
>
>
> On 4 August 2013 22:54, Peter Williams <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!
>

Sure it's a trade off.  But of course reputation should be transferable
from one identity or key to another eg via signing ...


>
>
>
>   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
>>
>>
>>
>>
>> On 4 August 2013 17:16, Peter Williams <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
>>>
>>>
>>> http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/
>>>
>>
>>
>
>
> _______________________________________________
> foaf-protocols mailing listfoaf-protocols@lists.foaf-project.orghttp://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
>
>
>
>