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

Reply via email to