Michael Ströder wrote:
Anders Rundgren wrote:
Michael Ströder wrote:
Ian G wrote:
* it has no open + effective key distribution mechanism. (I exclude
the LDAP stuff as that is generally for internal / corporates, and is
not a general solution for the users.)
Just exchanging signed S/MIME e-mails is quite easy for most users. The
case that e-mail receivers are completely unknown is fairly seldom. This
is a non-issue.
The e-mail receivers are seldom unknown but their CAs are. Using
Windows Mail most PKIX signed messages give me a black screen
telling there is something wrong with this message, while messages
asking me to download EXE files pass without warnings.
When I'm in a project working for a company which has a S/MIME CA
importing the CA cert into my S/MIME-enabled MUA is a no-brainer. What's
the issue? I establish trust for a certain purpose: Exchanging secured
e-mail with a certain company so nobody can read the documents *they*
want to keep confidential. I'm happy to do that once for a CA cert
instead of having to initiate a secure key exchange with every employee
of the company.
OK. I certainly understand the objective and the use-case. 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, and all email should go through
corporate servers, and TLS should be used for the protection.
(In this case, every user was either an experienced security and tech
person, or an extremely experienced security and tech person.)
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. Nor legal. To blame some other
process is what we call "shifting the burden," a pattern that allows us
to ignore the root causes.
The root cause is that the S/MIME security model is inefficient; it
doesn't deliver benefits in accordance with the costs imposed.
Funnily enough, users are very savvy. 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.
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.
And any other
signature/encryption/whatever standard will suffer from this.
If by "standard" you mean "security model," that's simply not true.
Skype delivers the goods and takes only a few minutes of training.
There is practically no training required to get users to use Skype in
its secure mode, because it nicely follows the idea of "there is only
one mode, and it is secure." Although it is not likely that we can move
email to the same model, it is entirely plausible to adopt 90% of the
ease-of-use, without losing any of the CA certificate benefit.
Of on the other hand you mean more literally, a standards-based security
model, then yes, that's true. 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.
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?
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.
But it is reality. Saying "you don't need to do that" is just ignoring
the problem by arguing some technicality which is totally irrelevant to
the way users have to live their lives.
Why do you think I claim that mobile crypto is a prerequisite?
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.
* 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. The PKI view is that this is done by referring to
the CPS. The secure browsing view is that it is done by the vendor, on
behalf of the user, and the CPS is reviewed by the vendor for that
purpose. (Yes, these two views are at odds, and the vendor has some
questions to answer here...)
One could surmise that this situation/confusion is good enough for
encryption between websites and users; given that there are lots of
other protections in place, etc. Indeed, this is our informal
preference here, in that we prefer to get more CAs in and and more
encryption happening, and this addresses the current threat scenario
which breaches secure browsing by exploiting its rarity.
However: one would be hard-pushed to suggest that this situation /
confusion could be acceptable for users to interchange legally binding
signatures, because there is an absence of other protections in place,
or those protections that are in place are uncertain.
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. 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.
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.
I believe Ian is referring to the problem which made me starting this
thread...
That is, the need for end-users to become trust managers.
Yes. Or, the absence of end-to-end trust management in the system, if
we are using that language.
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. Without info, it is called gambling. They are indeed
good at evaluation, given the limited resources that they can apply at
any time. However, as S/MIME does not provide any "circumstances" that
suggest a reliable framework for agreements, it should drop the
suggestion entirely.
(Users as a mass have already rejected S/MIME as a signing framework, so
this is more about protecting those users who might otherwise be
mistaken or might otherwise be sold a product by their IT supplier.)
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
