For me, the purpose of this debate is finding out what users can expect
from Mozilla by way of security. For the purpose of this question, we
see below that users can be divided into corporate users and individuals.
Michael Ströder wrote:
Ian G wrote:
Well, strange...
sure, snipping this.
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.
OK, so would you agree that this is not very useful for the non-company
people, like yours and my mum?
If so, if we agree on that, we might also say "well, companies can look
after themselves;" and/or "Mozilla has no offering suitable for secure
email for ordinary users."
I don't know about you, but I'm here at Mozilla to get a solution to
everyone. Companies come second in my book, because they can pay.
Probably, this is just a personal fetish of mine, and I don't mind being
told that Mozilla doesn't agree. But currently, its mission seems to
suggest that *all users* and especially non-corporate users are the ones
that Mozilla targets.
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.
Right, but that doesn't change the underlying economic model: the use
of S/MIME does not sustain itself. You need to put in fines or
penalties or additional costs in order to make it work. Without that,
it is not "economic". However, you always have to pay those
fines/costs/penalties ... and these need to be balanced against the
benefit of S/MIME. So even with the fees/rules/contracts, S/MIME is not
economic until you have shown the benefit.
This is a classical failing of the security world. Having established
the absolute need for "secure X" we then run around and organise the
business such that there are incentives to ensure "secure X". However,
there is no particular analysis that it was worth the cost, because it
is assumed to be "worth any cost".
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).
Except, the things found in modern standards are more security templates
or examples than models. They are more akin to recipes. If you have
threats like X,Y,Z, and you have business like A,B,C, then you can do 1,2,3.
Security models are individual to businesses and individuals. They
derive from threat to the persons, which again are peculiar to
businesses and individuals. WYTM? Without walking that path, we are
simply "protecting what we can" rather than "protecting the business."
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.
Good. So you -- and a few others here -- don't like Skype. However,
you are far out-numbered by the ones who do. Luckily, you have a choice
in your client software, and this is not a big issue for you.
However, my point in pushing these examples is not to get you to adopt
the product (choice!) but to consider the model (what you can get for
very little user interaction and zero paid cost). This architectural
model offers benefits that could be utilised by Mozilla's users, as
opposed to what corporate customers might pay for. More below on this...
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...
DNSsec, IPSec, S/MIME, PKI in general, WAP, WEP, ...
SSL was invented before it went to standards. SSH: same. OpenPGP
followed the designs of PRZ then PGP Inc. Hush was a private design.
Skype never made it to standards. New payment systems also tend to
avoid standards.
The point is that standards committees *may* be able to standardise an
already successful design; they do not seem to have any record in
creating new designs, nor fixing old designs.
As I say, correct me if I am wrong! Counterpoints might be: GSM?
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.
Right, this is out of scope for users. (And, sure, I have enough unix
experience to figure it out too, but, these days I treat such a thing as
a bug.)
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.
There is an assumption that private/public keys have to be treated as
key pairs, protected by the person and distributed to the public. This
may be ok for a system that is built that way, but it's only an assumption.
It's just architecture, private keys are to be used, not treated like
sacred objects.
Consider that most systems use password and username. This is *the
standard* albeit defacto. To move this to a "personal key store on the
net" scenario, we encrypt the private key with the password. Indeed, we
encrypt the entire account store with the password. This way, we can
log in from whereever and get access to the whole lot. The client
downloads the encrypted store, decrypts it with the password, then
extracts the private key.
Hey presto, an application that is better than today's standard.
And most of my friends (non IT people) don't use webmail. They
use MUAs on their PCs with POP3/SMTP.
It is odd! There are two big groups here, with no real favourites. The
market isn't giving us any clear signals.
* 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.
How so? How do you define any use of certs without referring to the CPS
or equivalent set of documents?
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.
That's partly the point. If the user can sanely untangle the stuff,
then well and good. I claim she cannot. If you-as-insider can, then
that's a start, but it needs to be put in a framework that is both safe
for users and understandable. That we haven't got.
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.
Of course.
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.
No, not at all. When you go to the bakery you get a brezel. The risk
of you not getting a brezel is very low. The information you get is
reliable, even if you do not "audit" the very making of your brezel.
This is called risk management.
(BTW, what is a brezel?)
When you go to the casino and put some chips down on the 00, you have a
1 in 48 (or somesuch) chance of getting a win. That's called gambling.
It's also highly reliable, you can calculate your odds, but the info
of the future event is lacking.
Huge difference.
Well, my feeling is that I said everything I have to say in this context.
It's a tough subject :) But I think we have got to the point where your
context is more or less the corporate usage, and my context is more or
less the individual user.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
