Re: [cryptography] The Government and Trusted Third Party
On 18/09/11 09:12, Jeffrey Walton wrote: If you can secure the system from the government... I can't possibly be the only one here that takes the following to be axiomatic: +++ A communication security system, which depends on a corporate entity playing a role of a ~trusted-third-party~, can not be made secure against a government in whose jurisdiction that trusted-third-party operates. +++ On the other hand, a perfectly adequate low-level retail transaction security system can best be achieved by using a trusted-third-party, SSL-like system. It follows then that we are not looking at replacing the SSL system with something better, but at keeping the current SSL - perhaps with some incremental improvements - for the retail transactions, and designing a new system, from the ground up, based on some a-priory, contemporary and well documented threat model. This new system should address those applications which have spilled outside of the (implied?) threat model on which the SSL design was based. That new threat model must not fail to explicitly state just who are the attackers are and what their capabilities and motivations must be considered. Mark R. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Government and Trusted Third Party
On 18/09/11 7:55 PM, M.R. wrote: On 18/09/11 09:12, Jeffrey Walton wrote: If you can secure the system from the government... I can't possibly be the only one here that takes the following to be axiomatic: +++ A communication security system, which depends on a corporate entity playing a role of a ~trusted-third-party~, can not be made secure against a government in whose jurisdiction that trusted-third-party operates. +++ Right. On the other hand, a perfectly adequate low-level retail transaction security system can best be achieved by using a trusted-third-party, SSL-like system. That's a marketing claim. Best ignored in any scientific discussion. It follows then that we are not looking at replacing the SSL system with something better, but at keeping the current SSL - perhaps with some incremental improvements - for the retail transactions, Actually, I'd say the above conclusion follows from normal inertia considerations. We can't wholesale replace SSL because there are too many links and lumps and levels and locales involved. So the question is, how to tweak the current application to deal with the mismatch between design and use? and designing a new system, from the ground up, based on some a-priory, contemporary and well documented threat model. This new system should address those applications which have spilled outside of the (implied?) threat model on which the SSL design was based. That new threat model must not fail to explicitly state just who are the attackers are and what their capabilities and motivations must be considered. This would be a classical text book approach, but is unrealistic. In the real world, figure out who is going to do this. The who will dramatically drive the process. Including the list of attackers, their capabilities, etc. E.g., if Google does it, we get one result; if China University School of CS do it, another result. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Government and Trusted Third Party
On 09/18/2011 05:32 AM, Jeffrey Walton wrote: The one thing I cannot palette: [many] folks in Iran had a preexisting relationship with Google. For an Iranian to read his/her email via Gmail only required two parties - the person who wants to do the reading and the Gmail service. Why was a third party involved? This is a good question and it's the starting point of some of the proposed solutions being floated (e.g. pinning). I think the answer comes from the realm of ordinary software engineering: state. (no, not State like the government, let's not get sidetracked here :-) The entire concept of a preexisting relationship adds new state to the client endpoint (the web browser). This might seem like a small thing, but it really isn't. To the extent a solution built on this observation is effective, this state is also security critical. Now that we have security critical state in the user's web browser, it add a lot of complication to the user interface. * A user may change hardware or reinstall the software, so now you need a mechanism to back it up and restore it, perhaps across vendors. Otherwise, the user's security actually regresses when they switch to a brand-new, clean and more secure PC. * The state probably needs to be private since it contains browsing history. * The state may become corrupted either maliciously or by accidentally. This could be as common as cert warnings are today. So now the users need a method to: - wipe out the state entirely clear the cache and cookies - delete entries selectively e.g., look through the cookies for the site and all the affiliate sites serving resources in into the page. - bypass the errors manually continue using the site anyway My personal view is that there's still probably a useful feature there if these issues can be overcome with some luck and heroically elegant software engineering. But if you're someone who believes that users always thoughtlessly bypass security warnings today, then you might see this feature as another damn the torpedoes full speed ahead button that users press when actually under attack. Note that out of over 300,000 IP addresses that made OCSP queries for fraudulent DigiNotar certs, there was only one user who had the presence of mind to ask about it on a help forum: https://www.google.com/support/forum/p/gmail/thread?tid=2da6158b094b225ahl=en This man deserves a medal and a place in history. Shall we make a Wikipedia page for him? Would the editors understand why he is noteworthy? - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Government and Trusted Third Party
On 2011-09-18 7:55 PM, M.R. wrote: It follows then that we are not looking at replacing the SSL system with something better, but at keeping the current SSL - perhaps with some incremental improvements - for the retail transactions, These days, most retail transactions have a sign in. Sign ins are phisher food. SSL fails to protect sign ins. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Government and Trusted Third Party
On 19/09/11 6:53 AM, James A. Donald wrote: On 2011-09-18 7:55 PM, M.R. wrote: It follows then that we are not looking at replacing the SSL system with something better, but at keeping the current SSL - perhaps with some incremental improvements - for the retail transactions, These days, most retail transactions have a sign in. Sign ins are phisher food. SSL fails to protect sign ins. Hence, frequent suggestions to uptick the usage of client certificates, SRP, and SSL itself. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Government and Trusted Third Party
Hi James, On 19/09/11 1:39 PM, James A. Donald wrote: On 19/09/11 6:53 AM, James A. Donald wrote: These days, most retail transactions have a sign in. Sign ins are phisher food. SSL fails to protect sign ins. On 2011-09-19 1:12 PM, Ian G wrote: Hence, frequent suggestions to uptick the usage of client certificates, SRP, and SSL itself. Client certificates and SSL seem unlikely to protect sign in. The point about SSL is two-fold: using SSL solves a slew of other problems to do with cookies and hacking and so forth, as Peter points out. I suppose we need a list :) The second point is that as more and more people use SSL, there is more and more pressure on the vendors to address the UI. Which leads into... The chairman of the board cannot handle a client certificate. He outsources that to someone in IT whose name he does not know. Not very secure. The problem with client certs is that they are mostly saddled with a horrible UI. If the UI was slick, it would work. The experiments we've conducted over at CAcert indicate that when it is up and going, and the user base is forced by one means or another to migrate, a properly written client-cert login procedure is far nicer and more secure than a password system. However, this requires to solve the chicken and egg problem. We did that in CAcert by some serendipitous decisions. How to do it in your org would be something else. http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing All of which are suggestions that there are low-hanging fruit. Tweaks to make the system work without redesigning. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
