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

reputation should be bound to persons (via their identifiers); not keys.


Keys (and security services such as signatures from keys) exist as assurance evidence, only. By analogy, the local names assigned to anonymous graph modes on processing the XML bearing the RDF graph don't get used as public references...


While one can (and spies do) perform behavioral analysis of such transient security metadata to build out inferences about membership of the cryptonet in order to attack and penetrate the clique, in open systems design one traditionally does NOT interfere with that. Its out of scope, in some sense. Of course, the standards have to be written such that one can “add” the military profile (for which the above is IN scope). Cost effective military “COTS” procurements can then be based on off the stuff we all use, with a win/win all around since the military “upgrade” requires a decent baseline (in windows/Microsoft and java/Oracle).


One saw this clearly in the X.500 world, in which public standards got profiled as F.500 standards for phone companies trying to run public identity servers, and profiles by NATO for military profiles wanting to run a joint multi-national campaign requiring identifies from disparate authorities to federate. In the latter, the profile might put the tuned up access protocol and its information (aka identity) model into an “application context” of multiple protocols, furthermore,  cooperating to augment the assurances ... or “protect”the transient metadata associated with protocol runs from cryptonet analysis.


For a while it was actually illegal to hide such transient metadata (without an export license). One thinks of the SSL handshake within a handshake, used originally to enforce US export controls limiting strong[er] SSL ciphersuites to a limited/vetted set of financial institutions. This hid the delivery of an inner security service (that acted to turn off software crypto limits built-into American OS products). It protected the US export service’s cryptonet (the list of banks it was in a deals with)


This kind of design hygiene seems to keep the peace AND keep us moving forward with delivering “useful” strong crypto. 




Sent from Windows Mail



From: Kingsley Idehen
Sent: ‎Sunday‎, ‎August‎ ‎4‎, ‎2013 ‎3‎:‎35‎ ‎PM
To: public-webid@w3.org
Cc: foaf-protocols@lists.foaf-project.org


On 8/4/13 6:26 PM, Melvin Carvalho wrote:








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 ...


Yes, of course. It doesn't require a single key. It just requires a Web- and Internet-scale verifiable identifier that denotes Agents. Your reputation is scoped to your name, ultimately :-)


Note:

1. http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fabout%2Fid%2Fentity%2Fhttp%2Ftwitter.com%2Fkidehen%23certF0549410169C0513116A03078AF5C59A992BBE57 -- Certificate (its also a signed claim example since you can lookup the signature too). 

2. http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fcertgen%2Fkey%2F8954 -- Public Key (which is paired with a Private Key) 

3. http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen -- WebID . 

Kingsley 






 











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 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









-- 

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