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

Of course the tradeoff between crypto and key management is the “art” of cryptosystem engineering (vs design). Apart from some vague “PGP trust model is the way forward”, I never got the feeling folks (or in webid) here really got to the root of the issue set. There was lots of emotion, but not much engineering in the dynamics of the key distribution.


One thing interesting about the hardness problem slideset  you cited was that - and this makes it pertinent to folks here - concerns a change in attitudes in the ws-security layer-7 messaging world. 


That presentation was ALL ABOUT TLS and DNSSEC-distributed ECC-signed zone files and RRs. Now, recall that VeriSign sold off its certs-business  for a last-gasp billion dollars ... keeping “only”its DNS business. Of course nothing really changed, as the business that it kept (DNS zone file management) gives DNS signed records - which are about to become the “new certs”  FOR TLS type world and endpoint-addressing-identity assurances. And, I cannot say I object - for the internet of 2020. But layer 4 and 3 are not where its at, in research.


Ws-security has “come down”to the world of office 365 cloud hosting , now existing as a bedrock technique. And, rather than securing transactions and conversations (making messaging-security compete with TLS), its little more than a binding mechanism, that gets you to session cookies. A SAML handshake to get tokens, the presentation of tokens, signed binding/association formation messages... gets you cookies that thereafter work their magic as (non-crypto) session-management devices. But, its very webby! its standard stuff for a Microsoft to already be processing a billion such events a day.


That'sits now the BEDROCK of huge numbers of folks doing cloud-based outsourcing of mail, voicemail, groupware...should be indicating something:- TLS is NOT WHERE ITS AT (for the web). TLS is tied to the world of false cert issuing, ISPs with spying devices, Google/Microsoft/Yahoo with police-imposed port monitors, etc - the whole spying/surveillance world.


But, fortunately, I think webid folks figured that out - about a year ago - that TLS/https  for client/server is not the right webby model - anymore. And, the market told us that the TLS handshakes and session-resumption recast in layer7 soap packets (per ws-security) was no better, either. What one needed was a simple crypto-binding - to get to inter-domain session cookies. Then you do key refresh to replce cookies as often as you wish, since making ephemeral keys is now cheap.


(The first 512 RSA key I ever made, using a library from a Cambridge math type, took 2m in 1991, and had taken him 7m on a DEC ultra 2 years earlier - all to address a “GCHQ chief mathematicians challenge to the pending graduating class at Cambridge math/CS group” By 1995 the chief designer of MIPS was happily predicting 1000 1024-sig verifies a second, on a 100$ PC-card “extension” board).


Sometimes history helps give context. There is plenty of life in RSA, yet;  particularly as “officials” try to arrange its demise (along with certs, https). MD5 lasted 15 years after it was “compromised” theoretically;and even then was “useful” (as a cyber-attack vehicle)




Sent from Windows Mail



From: Melvin Carvalho
Sent: ‎Sunday‎, ‎August‎ ‎4‎, ‎2013 ‎2‎:‎34‎ ‎PM
To: Peter Williams
Cc: public-webid, foaf-protocols@lists.foaf-project.org







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


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


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


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





So there's a trade off between security and key management.


 




 

 

 

 


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/