On 28.09.2010 20:14, mathew wrote:
On Tue, Sep 28, 2010 at 11:36, Kai Engert<kaie(_at_)kuix(_dot_)de> wrote:
Wouldn't it help to introduce an universal mechanism that makes forgery
difficult, in order to make sender addresses in emails more reliable?
We already have S/MIME, which almost every common e-mail client supports (1).
Yes, I'm aware, I've been contributing to make S/MIME available in
Mozilla Mail and Thunderbird since 2001.
http://tinyurl.com/3ac258p
Nobody (2) uses it. Hence I suspect that validating sender identity is
less valuable to people than you think.
I don't agree with this conclusion.
There could be many reasons why a technology is not being widely used,
despite being widely available. How many owners of video tape devices
didn't ever use the timer recording feature because it was too
difficult? How many users of modern mobile phones don't ever use
anything but calls and texts, because they aren't motivated to learn how
to use the additional features?
With regards to S/MIME, I believe the reason for lack of wide adoption
is simple. It's too difficult to use for most users.
In order to use S/MIME, one has to overcome many hurdles:
- decide to use it
- understand what a cert is
- find a place to get a cert
- don't give up when you learn that a cert often costs money
- if you don't like to pay, find one of the free cert providers that
won't charge you for it
- install the cert on every computer you're using
- as soon as you start using S/MIME for signing, you'll likely start to
receive encrypted messages (although, yes, one could use signature-only
certificates)
- realize that you can't use S/MIME on your mobile devices, because most
mobile email apps don't support it
- receive an encrypted email on your mobile device, be unable to read it
there, because of lack of support
- be frustrated that you can't read encrypted incoming email when using
webmail to check your inbox, e.g. while on vacation, or at a family
member's computer
- have to renew the cert every year and repeat the whole procedure
- your harddisk breaks down, you have forgotton to make a backup of your
private key, and you can no longer decrypt and read your old messages
- you must be careful to keep all of your certificates and their private
keys you had used during the previous years, in order to be able to read
your old archived encrypted messages
- decide that you want to continue using S/MIME by default for all your
messages despite all of the above
I believe these are too many hurdles.
From my perspective, as of today, S/MIME is a privacy technology, and a
user must be willing to invest the resources to make it work.
Because of the above I think it's unrealistic to expect that S/MIME will
be used as widely as necessary for it to help against spam.
I have constructed the SpamSalt proposal to make management of a user's
signing key as easy as possible for the end user. I believe that's the
strength of the idea.
I think enhancing an email application's configuration with one more
secret key, in addition to the password, and calculate and verify hashes
is much easier than implementing a full S/MIME client with it's needs
for certificate management etc.
And many users use webmail. S/MIME keys are supposed to be known only to
the individual, not to the provider, because the intention of S/MIME is
privacy.
With S/MIME you have the problem that you have multiple issuers for
certificates, and that email provider, revocation checking provider are
separate entities.
With the SpamSalt proposal, each email provider can manage and revoke
keys on their own.
And I don't think that the
popularity of webmail clients which fail to support it is the reason;
rather, I think the reason that webmail clients don't support it is
that nobody cares.
I mean, even my bank doesn't care.
You mean, they don't use S/MIME when exchanging email with you?
I believe they don't bother because it's too much work to use it.
I presume that each of the previously proposed flavours of signing might
have had properties that made them difficult to be deployed universally.
For Apple Mail at least, once you have your certificate file you
double-click it and everything gets configured automatically; then you
can just check a box when composing e-mail in order to sign it. The
recipient doesn't have to do anything; the message will show up in
Thunderbird, Mail, Notes etc. as correctly signed.
Maybe there is one vendor that has a much better implementation of
S/MIME than other vendors, but I believe the hurdles I have mentioned on
the sender's side applies to most implementations.
So the biggest difficulty of S/MIME is that you need to go to a web
site and verify your ID somehow in order to get a certificate file
that you can feed to your e-mail client. That's pretty much a
fundamental issue independent of the specific technical
implementation. If you've thought of a way to avoid that issue, I will
be astounded.
I don't have a way to avoid that issue. I know several people who would
love to see the process simplified or even fully integrated in email
clients.
And regarding SpamSalt, the simplification I propose is to have the mail
provider issue the keys.
S/MIME is capable of ensuring a real world identity, while the SpamSalt
key would be a proof of mailbox ownership, asserted by the mail
providers, even anonymously.
There are some smaller difficulties, like buggy IETF mailing list
software that breaks the signatures, but those would probably get
worked out pretty quickly if people cared enough to use S/MIME...
There are several modifications performed by transport agents that break
email signatures. Quoted printable encoding inside the body, whitespace
changes, and changes to the MIME boundaries. These are a problem. I've
frequently seen messages with broken signatures because of this. This is
why I have mentioned the need to define how to reverse encoding to a
normalized state, before a message is used as input for hashsum
calculations.
So, instead of S/MIME, I'd like to propose to use a simpler flavour of
signing for an email anti-forgery solution, where proof of mailbox
ownership should be sufficient.
If we keep both technologies separate, it will be possible to combine
the anti-forgery mechanism SpamSalt and the privacy mechanism S/MIME in
a single email.
Kai
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg