Ian G wrote:
Michael Ströder wrote:
Anders Rundgren wrote:
Michael Ströder wrote:
>
I can offer a counterpoint: a recent well-thought-out project to do
something similar started out with S/MIME, and concluded that S/MIME
should be optional because it is brittle,
The phrase "because it is brittle" does not give any particular reason.
So it's impossible to answer in a meaningful way.
and all email should go through corporate servers, and TLS should be
used for the protection.
And how did you ensure that *all* of the relevant communication partner
had StartTLS enabled at their MUAs, all MUAs were corporate servers
(especially the receiving MX) and how was CA trust handled? Pretty
similar problems...
(In this case, every user was either an experienced security and tech
person, or an extremely experienced security and tech person.)
Well, strange...
The unexperienced users I've teached to use the existing S/MIME
infrastructure were capable of doing so.
The sad thing is: The users, in this case my project colleagues,
sometimes do not know how to use the existing S/MIME infrastructure
although they enrolled during a user registration process and they
already have everything on their desktop. Although I'm not involved
personally with the S/MIME infrastructure my attitude is to teach the
people how to use it. And they feel better when using it because they
know there's a need for e-mail protection. But they were simply not
teached. That's a non-technical problem.
IMO, the root cause is not training.
The root cause is that protecting e-mails is not enforced/endorsed
within companies even if they have a working infrastructure. The lack of
training is the consequence of this.
Nor legal.
Yes, not a legal issue.
The root cause is that the S/MIME security model is inefficient; it
doesn't deliver benefits in accordance with the costs imposed.
I disagree (see above).
Funnily enough, users are very savvy.
I agree (see above ;-).
They can spot a worthless system
much more easily than engineers. What they can't do is explain why it
is worthless; they simply bypass it. This is why smart product is
always developed in association with lots of user feedback, and paper
designs generally don't succeed.
As I wrote the users themselves felt better after protecting e-mails
with encryption. They are savvy. They know that it's bad not to encrypt
e-mails.
In another project my task was to explicitly support external partners
of a company with a S/MIME infrastructure to get S/MIME-enabled. A
normal user from within that company had triggered this support request.
I tried to contact the admins of several external partners to help them
but they just ignored it. => the lack of security requirements in the
contracts were the root cause for failure. This has to be enhanced.
In this sense, Mozilla is on the right track with trying to put in place
a user security model that doesn't require user intervention. (E.g.,
the UI hides the CA, from the "all CAs are equal" assumption.) However,
this only works if the result is efficient. As Kyle comments, it isn't,
for S/MIME, and the result is that the model experiences low usage rates.
In any case the sender *and* the receiver has to enabled for e-mail
protection => the very same problems will arise.
And any other signature/encryption/whatever standard will suffer from
this.
If by "standard" you mean "security model," that's simply not true.
Yes, IMO the security model is part of a standard (cryptographic protocol).
Skype delivers the goods and takes only a few minutes of training.
I don't trust Skype! AFAIK the protocol and security model was never
publicly reviewed. And it only works with access to a central
infrastructure. I'd never accept such a thing.
Correct me if I'm wrong, but I don't
think any standards approach ever came up with a security model that
works for users.
A pretty broad statement...
E.g., after changing laptops recently, I still cannot s/mime to half
my counterparties because I don't have their certs. This happens
regularly with everyone I know...
???
I've changed my notebook harddisk quite often. I never lost my
Seamonkey
cert DB containing the key history of the last 10 years since it's part
of the Mozilla profile which I have backups of.
It is a curious thing: I have been using Tbird for many years, and each
time I've never managed to transport more than a portion of the stuff
across. I just spent some time looking and couldn't find the magic
command, so I always wonder... I know there is a thing called profiles,
but where does one import & export them?
By simply copying files? That's how I'm doing it.
Each time you want to use another computer.
Oh, come on! How often do you *really* do this? And how do you move
around the rest of your workspace? There are many more things to
consider when you want real roaming than just your keys and PKCs of
others.
Sure. It's a nightmare. I do it around once a year at least -- full
migration. This year, three times. I hate it.
Migration is something else than Roaming. Migration happens not so
often. Even if you personally feel that three times per year is quite
often. Which I fully agree it's a pain. But migrating keys is least of
the work.
In opposite to that Roaming means you switch workstations every day or
even multiple times a day and can use your complete environment without
any additional work. In practice this does not work for power users.
Either your mobile also runs the apps or you have to integrate your
mobile with the PC on which the
whatever-you-call-your-standard-enabled app runs. The latter is the
same problem space like using smartcards/readers or USB tokens as key
store.
Right. Guess what: user-oriented applications like webmail, google
tools, skype (cough!) and so forth solve this problem by integrating the
entire database into some form of network store.
I wouldn't trust anybody to run my personal key store on the Internet.
Period. And most of my friends (non IT people) don't use webmail. They
use MUAs on their PCs with POP3/SMTP.
* it needs a few tweaks in UI to align it with the safe usage
models,
so, for example the "signing" icon has to go because it cannot be used
for signing, because signing is needed for key distribution. It also
cannot be used for signing unless reference is made to the
conditions of
signing, and no UI vendor has ever wanted to give time&space to a CPS.
Maybe it's me but frankly I don't understand what you say here.
Especially I don't see the need for a "UI vendor" to define a CPS (if
Certificate Practice Statement is meant here).
Not quite, what I mean here is that somehow, the user has to figure out
what is happening.
Yes.
The PKI view is that this is done by referring to
the CPS.
No.
Recall Nelson's view that he does not sign anything without reading. The
wider principle here is that one should not enter into an agreement
unless it is understood.
Yes.
Now, applied to S/MIME, if it implied some
form digital signing over emails, then it should not be used, because
one cannot read the implied contract (CPS, or whatever), and nobody else
is stepping up to say it's ok, sign away, we're watching your back. Full
understanding is not possible, at any of many layers and levels.
Whether one would like to use S/MIME to sign something legally binding
is beyond my scope. That would be a business decision evaluating the
risk in a certain context.
In order to satisfy users' needs for clarity, the governance UI should
present a workable human signing view to the user. But, as we have seen
in recent threads, that is fantasy. It's a non-starter.
Ergo, S/MIME client UI implementations should be modified to drop any
sense of signing, by default, and the digsigs should be used for
integrity protection and key distribution.
You're wildly mixing stuff here.
Everybody is a trust manager. All day everybody is making trust
decisions. But there's no ultimate trust.
No user can make a trust decision without evaluation of the
circumstances.
In fact evaluation of the circumstances is never done completely.
Without info, it is called gambling.
Yes, that's exactly what we all do each and every day when making trust
decisions:
If I go to a bakery in the morning buying a brezel for breakfast I have
a very vague idea of whether I can really trust them for not doing any
harm to my health with the food they are selling. Even though this shop
has a certificate in the sales room proving that this baker has the
title "Meister" (needed in Germany) it's completely impractical to
evaluate all the circumstances of this little deal. So yes, it's simply
gambling with high risks.
Well, my feeling is that I said everything I have to say in this context.
Ciao, Michael.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
