ietf-asrg
[Top] [All Lists]

Re: [Asrg] Spam Salt, an email sender authentication mechanism

2010-10-26 15:15:57
 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