Subject: RE: [Asrg] How to defeat spam that uses encryption?

From: Jason Hihn <[email-masked]>
Date: Tue, 01 Apr 2003 10:01:59 -0500

Well, you don't need a formal PKI that does end-to-end encryption.
If you encrypt between mail servers, and let the last leg be unencrypted
you'd get the same effect (keep POP3, IMAP for incoming, SMTP outgoing, but
once at the server, the server can use it's own randomly and routinely
generated keys, it just has to honor any incoming mail generated on a
recently expired key)

While that is NOT authentication, it does get us a level of control. Pub key
denial (due to blacklist) is one advantage. Another is the lock-step nature.
A down side is unless the server serves out keys for accounts it doesn't
have, it can be used to validate accounts. Still, with a good RBL, the
effects should be minimal, as any spamming server will be denied.

Also, because the server holds the keys, it can still scan the messages.

Note, that this still works without "encryption" if we change our thinking
to "tickets" (permission to send to an account, because that's all we're
really asking for) everything above still works.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hallam-Baker, Phillip
> Sent: Monday, March 31, 2003 8:33 PM
> To: [email-masked]
> Subject: RE: [Asrg] How to defeat spam that uses encryption?
>
>
> > > From: "Eric D. Williams" <[email-masked]>
> >
> > > ...
> > > All: A question is the discussion of end-user MUA
> > technology uses of encryption
> > > something people want to address as a 'spam' control solution?
> >
> > It's a complete non-starter and waste of time, because it suffers
> > the threshold problem in the worst way.  Early adopters get no
> > benefit and many hassles.  Despite decades of work, the mechanisms
> > to distribute keys are practically useless.  The user interfaces
> > are coming along, but they're still poor and sometimes just
> > don't work.
>
> The mechanisms designed to distribute keys are fine. The problem
> is the attempts to use X.500 and LDAP for this purpose which are
> longstanding abject failures.
>
> The problem with encryption is that encrypting a message says
> NOTHING about its authenticity. I can send you an encrypted
> message that purports to be from anyone I choose. To get any
> statement about authenticity you need a signature.
>
>
> > You can sometimes justify the practical hassles of encryption for
> > keeping your communications private, but that avoids the threshold
> > problem.  Many of us have used at least PGP for professional reasons,
> > but that's a whole other world.
>
> Don't project your experiences of PGP onto PKI. PGP has a very
> specific design which is fine for its intended purpose but that
> is not to provide a PKI.
>
>
> > Encryption, whether signing by senders or decrypting by receivers, is
> > useless against spam until almost all of your correspondents use it.
>
> It is useless against spam at any time.
>
> Authentication is useful as a means of bypassing spam filters and
> avoiding false positives even if relatively few people use it.
>
>
> 		Phill
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Tue, 1 Apr 2003 05:31:18 -0800 (PST)

There is nothing stopping spammers from generating new keys and certificates
for their mail servers, so we can have servers exchange certs, but really 
not authentication there as far as who is who.

Slightly better is if server must have a public certificate verifyable 
though DNS, then whatever name is at EHLO, it can be checked at DNS and 
then you know who it is. This does not stop spammers from adding their 
certs into dns either, but at least then we are requirying them to have 
valid dns record for mail server and they really do not like that idea... 
(but they can still just get new domain for $6 which is real cheap as far 
as preventing abuse and changing domains all the time - to stop some kind 
of ip block verification has to be done or DCC like system).

In the far future, this can possibly be tied to reverse ip certs. Currently
there are discussions on possibly distributing certs to ISPs by RIRs (for 
S-BGP - yes I know - its somewhat unlikely in the next few years) and if 
properly used you could have the ISP when gives ip block to customer, it 
could be required to sign their domain cert, then we have some level 
of signage from central authority (i.e root dns->RIR->LIR->ISP->Domain 
Host->Mail Server->User) but I'm just dreaming here...

---

From: Chuq Von Rospach <[email-masked]>
Date: Tue, 1 Apr 2003 08:56:04 -0800

> not authentication there as far as who is who.
as a friend of mine who's a computer security expert keeps reminding 
me, authentication is not authorization. The fact that someone can get 
authenticated doesn't say anything about what that person can (or 
should) be able to do. It merely means you have some idea who that 
person is supposed to be.

It doesn't matter how good the authentication scheme is if there's no 
way to turn that into  what a person is authorized to do. That's a key 
problem with certs and many authentication schemes. Given how easy it 
is to get or generate certs, and given that even if you authenticate 
sites and can blacklist certs that spam, if certs are effectively 
throwaway tools for spammers, what good does blacklisting a cert do?

authenticating a stranger doesn't buy you anything, because you still 
don't know what permissions you can trust that stranger with. 
authentication is mostly of advantage for whitelisting operations and 
clearing stuff out of the way that you know you don't have to look at, 
at least until someone grabs someone else's cert...

---

From: mathew <[email-masked]>
Date: Tue, 1 Apr 2003 18:00:50 -0500

On Tuesday, Apr 1, 2003, at 11:56 US/Eastern, Chuq Von Rospach wrote:
> me, authentication is not authorization.

Correct, and furthermore identification is not the same as either 
authentication or authorization.

This is why SSNs are such a problem. People try to use an 
identification number for authentication and authorization.

mathew