On 24/3/09 01:48, Eddy Nigg wrote:
On 03/24/2009 02:25 AM, Ian G:
I haven't followed it in depth, but the primary way that the E.B.s
have responded is to move their existing TAN system to a cellphone SMS
(which the europeans call "handys", brits call them mobiles). A TAN is
a transaction authentication number which is distributed on a paper
sheet to users. When the transaction is finalised, the user types in a
TAN taken from a supplied index like row,col, and crosses it out on
the paper.
In other words OTP by mobile and SMS?
More or less.
Ah. So, I see this is migrating to "use popular Internet RFC standards
for security." The problem with this is that some of them -- like
S/MIME -- are practically worthless whereas some of the non-RFC
standard products like Skype are very secure.
Arrrg, we have been there already...but not going to repeat myself,
:)
instead I'm asking you, how would you secure email
OK, just quickly, coz we are way off topic.
Two caveats: Firstly, email is the clunkiest awfulest of communications
apps, and is very difficult to secure on a general scale. We don't
design things that way any more, and difficulty of securing is one
reason for that.
Secondly, in order to secure any proportion of it, we have to move
quickly and *easily* to a very large proportion of secured email
clients. Without that, we face the problem that any group larger than a
handful will have a small number of people in it that doesn't have the
security client, so it will fail.
We therefore have to be very aggressive with those Assumptions that Kyle
speaks about. Another way of putting it is that the perfect is the
enemy of the good.
The question reduces to how we would fix the client software to
bootstrap into full crypto mode with no user intervention. Because user
intervention is the killer. Let's assume zero user intervention, no
more than necessary for email itself.
This would then mean that on adding an email account into Tbird, it
automatically creates the public key pair. On each email sent out, it
includes the public key in a header. On each email received, it grabs
out any public key sent and stores it in the address book. On every
email going out, it sends it encrypted to that person.
The rest is sugar-coating or icing.
(since IM isn't the
same thing really and different protocols/products are seeking different
solutions, even within the IM family).
Right. Every context requires a different top-to-bottom solution.
(Hence, today's subject line. What can we do to make client certs
actually reach out and deliver to users? Today's task: solve the
session problem.)
Haha...that's a good one... :-)
(I use S/MIME every day too, and over TLS. I also suggest that the
other security people use it and be abused by it, maybe because I am a
sadist :) Although not scientific, here are some results: within this
one highly-motivated security community of around 20-40 people, I see
about a 60% success rate in install + certificates, and something less
than 10% success rate in delivered secure messages. E.g., worthless.)
It needs some coaching sometimes, but it certainly works...
Oh, it probably meets RFC spec, and it can be rolled out in closed
environments (govt.s and corps) where there is strong institutional
force for turning off normal user behaviour.
It just doesn't deliver security in the real world context of the net's
users, in Mozilla territory. OpenPGP is much the same, but for
different reasons.
now I'm
interested which improvements you would suggest (besides lets ditch
S/MIME and use PGP).
Assuming S/MIME, as above. Create the key pair as above. Wrap it into
its cert. Deliver the cert into the headers. Cache the things.
Where it gets interesting with S/MIME is that once we eliminate the
famous Assumptions, it starts to look more plausible. Adjust the GUI to
display the status of the cert that is currently in question: don't
punish the person for the wrong cert as currently done, but create a
marketing step up to the CA-signed product. Add the keyservers, perhaps
as a special for CAs.
(BTW, I guarantee you that this will sell more certs. We might validly
ask why this is not already done, because it will make a *lot* more
money for some CAs. But that's way way offtopic :)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
