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

From: Kai Engert <[email-masked]>
Date: Tue, 26 Oct 2010 22:14:55 +0200

On 28.09.2010 20:14, mathew wrote:
> On Tue, Sep 28, 2010 at 11:36, Kai Engert<[email-masked]>  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

---

From: Franck Martin <[email-masked]>
Date: Wed, 27 Oct 2010 09:10:05 +1200 (FJT)

I have written a while back the SSL Certificate HOWTO, and while I was doing it I found out, that's it is near impossible to get a signing certificate. I mean a certificate that allows you to sign the certificates you produce.

GPG was a bit better because it does not require an authority (would I dare to say a licenser).

We have the same issue with IPSec. Great spec, very secure, totally unusable.

IETF is not well know to make good user interfaces...

Franck Martin 
http://www.avonsys.com/ 
http://www.facebook.com/Avonsys 
twitter: FranckMartin Avonsys 

Check your domain reputation: http://gurl.im/b69d4o

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 Oct 2010 15:17:04 -0700

On 9/28/2010 9:36 AM, Kai Engert wrote:
> difficult, in order to make sender addresses in emails more reliable? As of
> today, I can't see anti-forgery mechanisms being used in most emails I receive.

By sender, I assume you mean "author".

As for email address, that's very nearly irrelevant and it is most definitely 
irrelevant on its own.

What matters is the identity that the from.angle-addr and the from.display-name 
are tied to, and maybe the same for the rfc5322 sender address.

While the comments about usability are certainly correct -- currently usability 
sucks -- there is also an enormous barrier of mapping between the online 
identifiers and a meaningful identity that a recipient can understand and care 
about.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 27 Oct 2010 06:29:37 -0400

It doesn't matter.  The entire issue of end-user authentication is
dead, dead, dead thanks to 100+ million zombies with keystroke loggers.
It doesn't matter how clever the tech is, how slick the UI is, how
minimal the effort is.

(Incidentally, I note with interest the reported takedown yesterday of
the Bredolab botnet, whose size is reported as 30M.  If that's accurate,
that is, if a single botnet has hit the 30M mark, then it's past time
to make the working guesstimate of bots something like 200+ million.
Not really surprising: we're still on a march toward the point in time
where an end-user system, chosen anywhere in the world at random,
will have a 50-50 chance of really belonging to someone else.)

---rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 28 Oct 2010 01:29:37 -0400

> It doesn't matter how clever the tech is, how slick the UI is, how

Oh, then, port 25 blocking and SMTP submit authentication is dead dead 
dead too, predicated on the _same_ zombies and keyloggers?

Actually, it's not, at least on the sending side, because for various 
reasons, botnet writers haven't (with only trivially small exceptions) 
done it.

On the receiving side, yes, the volume is still gruesomely high (because 
of sites that haven't/won't see the light), but (a) it'd probably be 
MUCH higher without it and (b) you can often use knowledge about who 
don't (and where their IP space is) to block it anyway (cue SORBSDUL, 
PBL, EL etc) or (c) partially evolve to "default block" approaches.

Certainly, the equation would change if "everybody did it", but it could 
provide considerable breathing space, and perhaps change the spammer ROI 
sufficiently to get more of them out of the biz.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 28 Oct 2010 11:39:35 +0100

> reasons, botnet writers haven't (with only trivially small exceptions)

Here, we block outbound port 25. It means that all SMTP traffic on port 25 
has to pass through our MTA. That doesn't stop the occasional abuse of 
compromised accounts, but it does mean that we can monitor traffic. For 
example, we rate limit users when they're off campus. And, we monitor 
volumes from on campus sources.

Of course, there's still the possibility of trickle feeding from 
compromised accounts, but that makes the accounts much less valuable than 
they otherwise would be.

> of sites that haven't/won't see the light), but (a) it'd probably be MUCH
> higher without it and (b) you can often use knowledge about who don't
> (and where their IP space is) to block it anyway (cue SORBSDUL, PBL, EL
> etc) or (c) partially evolve to "default block" approaches.
>
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Oct 2010 11:44:02 -0700

> reasons, botnet writers haven't (with only trivially small exceptions) 
Compromised accounts sending spam through ISP's outbound servers is 
steadily increasing.  For some large providers, the number of accounts 
have increased significantly.  Botnets tend to avoid detection by 
sending only a few messages through each account to stay within the 
statistical noise.

The NoScript plugin for Firefox and Secunia's Personal Software 
Inspector (PSI) are excellent tools for reducing exposure levels.  Even 
so, the online software industry operates in a reactive fashion where 
weeks or months of exposure might exist between a zero-day exploit and a 
security patch.

Social networks, email, and popular websites offering ad malware remain 
popular tools of the botnet trade.  At times, ad malware is the result 
of malicious browser modification and not the visited website.  The DNS 
RPZ approach might become the Domain equivalent to that of an IP address 
RBL.

-Doug