Subject: [Asrg] Email Certification Path Proposal

From: "Alejandro G. Belluscio" <[email-masked]>
Date: Mon, 10 Mar 2003 19:06:32 -0300

Hello list,

I have this proposal. I can re send it in PDF if you don't like the text
edition.
I know it's too early to send this kind of proposal, but please keep in
mind the idea that, if signature is required, use the existing business
relationships instead of making the Verisign mistake again.

------------------------------------
Email Certification Path Proposal.

Author: Alejandro G. Belluscio
IIGECI
Argentina

Sending Account (SA): refers to the Legal Entity or person identified by
a given user and password within an SMTP authorized users domain that
originates an email.

Recieving Account (RA): refers to the Legal Entity or person identified
by a given user and password within an SMTP authorized users domain that
recieves an email.

SMTP Manager (SM): The legal entity managing a SMTP server.

Unsolicited Mail Claims Account (UMCA): an email account set up by each
SMTP. Manager to exlusively recieve signed emails sent by a Sending
Account of his domain that are claimed to be Unsolicited Email. This
account should discard any email not signed by his own certificate or a
certificate directly signed by himself.

Unsolicited Mail (UM): I will not define unsolicited mail, because this
is a consensus definition. But I'm trying to make this proposal so
anyone in this system thinks that in good faith he's not really
bothering recipients when sending mail.

Offending Mail (OM): Mail that's percieved by the reciever as "not
wanted to be recieved". Note that this definition is flawed too, but its
not the core of the proposal.

Sender of Unsolicited Mail (SUM): Self explanatory given the
undefinition of UM

Unsolicited Mail Claim (UMC): A signal from a reciever of an email that
certain email was not solicited and clasifies it as "spam". Please note
that this is subject to change and open to discussions.

Objectives
-To have a certified sender in the sense of a legal entity .
-Keep the privacy of the sender and reciever when necesary.
-Minimize the cost of entity certification.

Description

1. Each SMTP has to enable SMTP-AUTH. This enables the server uniquely
identify the Sending Account sending such mail.

2. Using that information the header is then added a signature using a
certificate of the SM plus a code that let's said SM to uniquely
identify the Sending Account. This code should be chosen so as to be non
descriptive of said account for a third party, even if he recieves
multiple emails.

3. An UMCA belonging to the SM and one belonging to the direct signer if
his own certificate is added to the header signature.

4. (to discuss or optional) On a recieving SMTP if the email has a valid
signature path, it's signed by himself and given a code that let's the
SM uniquely identify the RA.

5. (from now on I'm over extending a bit) Should a user regard an email
as unsolicited he should:

   a. If his MUA supports this system, the OM should be sent
   (verbatrim?) as a UMC to both the SM's and it's immediate certificate
   signer's UMCA.

   b. If his MUA doesn't support this system, the RU should forward it
   to a given account by his own SM that automates the point 5.a task.

Benefits

-This system allow a positive identification of the offending SA.

-It automates most of the task of identification of SUM while keeping a
certain degree of privacy to both SA and RA.

-It also minimizes the cost of certification authorities by using
existing business relationships.

-This system can be rolled with no intervention of the end users save
configuring SMTP-Auth (which many ISP force anyway). Some work on MUA
might be necessary but only to automate further the task.

-It significantly reduces the cost of processing UM by automating the
processing of emails that complies with this standard.

-It keeps the authority of ISPs intact.

-We don't create some artificial new authority.

-There's no reason fees should levied for the signature since it should
be just a simple more step in the setup of an account in an ISP,
backbone provider, etc.

-The incidence on existing protocols is nil.

-MTA should need a rewrite, but may use the signature infrastructure of
SSL, so the effort should not be too high.

Bad

-Increase in the size of every email by a fixed amount. So if email's
keep getting biggers this cost as a proportion decreases.

-MTA will need to be rewritten.

-The cost of resources for the SMTP. The ongoing trends of speed
increase and encryption acceleration in the mainstream CPU may offset
part of this cost in with time, but for high volume servers custom
hardware acceleration of the signature might be necessary.

-It's pure network economics. It might be very difficult to apply at
first since there's little benefit unless "everybody" is in the system.

-The absolute usefullness of the system can only be achieved with a
change in the MUA. Unless the system is so successful that the SM can
"reasonable" configure it's server to deny any non-signed message.

Rationale

The idea of sending the UMC back to the SM is to send a certain
"evidence" of the action and to allow the SM to keep a statistic
regarding any given SA and UM.

The idea of sending the UMC back to the SM's certificate's signer is to
allow him to keep statistics and a certain degree of control that the SM
is making his job. In a sence it's a tool to keep his own signature as
good.

Certification Authority Path.

Root Certificate Authorities

The upper certification authority should be the RIR or IANA. Since they
have actually make the effort to positively identify the organization to
whom they have given IP numbers, the cost of certifying it's true
identity it's already made. It also mreduces the number of CA to a small
stable number. They must provide certificates with the possibility of
making further signatures.

Second Level Certificate Authorities

The following level should be the backbone providers who sell bandwith
and connection services to ISP. Again, their customers are known and
providing a signature should be a minimum cost. They must provide
certificates with the possibility of making further signatures. For its
final clientes they should make an third level certificate and sign with
such certificate non signing certificate.

Third Level Certificate Authorities

The ISP should implement part of the SMTP protocol for the small clients
and may sign the certificate for well known, big customers. The
certificates thus signed should not be able sign further certificates.

Fourth Level Certificate Authorities.

Customers who want to have their own SMTP server should have them signed
by their respective ISP.

TODO:

Policy for revocationg signatures. When do we consider that some ISP
hasn't made his work?

The specifics of the PKI. Some of the PGP standard might be applied
here. My take is to use the SSL ceritfication part, without the
encryption.

Common registry of revocated Legal Entities. So known spammers can't
sign up an ISP that wants to be in this system.

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

---

From: [email-masked]
Date: Tue, 11 Mar 2003 02:05:45 -0500

> relationships instead of making the Verisign mistake again.

And my business relationship to you is what, exactly?

This isn't a rhetorical question.  There's only a few basic trust models:

1) Our respective cert authorities negotiate a private cross-cert
agreement.  This works well for 2 businesses that want to verify each
other's signatures, but doesn't scale to the open internet.

2) a Verisign/X.509 model where somebody runs a central set of servers.
Nobody is going to do one of these that scales to Internet size for free
either (hint - what percent of domains have their own CA that can sign
certs for their users?)

3) A PGP web-of-trust model.  Works great once both correspondents are in
the same web, but has some major bootstrapping issues...

The "Verisign mistake" happened because there aren't a lot of other things
that *could* have happened.

> (lots of definitions skipped)

> -Minimize the cost of entity certification.

Reasonable goals..

> identify the Sending Account sending such mail.

Nice hand-waving.  How do you ensure that the *REMOTE* end actually enforces
it?  This isn't as easy as it looks - *my* mail systems may do SMTP AUTH,
and I may even pass a cookie to you so if there's a problem with one of
my users, you can give me the cookie and I'll hopefully know who to call
in and beat the snot out of them (which was the *original* purpose of
RFC1413 IDENT, incidentally).

Of course, a spamhaus already knows who's using their server, and has no
need of running SMTP AUTH to verify that they themselves are the ones
sending the mail....

> desiptive of said account for a third party, even if he recieves
> multiple emails.

Read RFC1413, section 6 (Security Considerations)

You're trusting the remote site to give you information.

> SM uniquely identify the RA.

Signed how?  and what makes this more trusted than the set of Received:
headers?

There's two cases to consider:

1) There exists a PKI.  In this case, the sender just uses S/MIME or PGP
or whatever, and all the intermediaries need do *NOTHING*.  This message is
PGP signed - if you want you can validate it via the PGP web-of-trust.  And
my mail server, your mail server, and the IETF mail server need not get
involved at all.  If I sign it with an X.509-style cert, the mail server
STILL doesn't have to get involved, because the cert chain on my signature
already identifies me.

2) There isn't a PKI.  If so, then everybody is basically just using self-signed
certificates, which prove approximately nothing...

Note that doing crypto on a hop-by-hop basis will get *expensive* - the note
that I'm replying to had 8 Received: headers, and 15-20 is not at all
uncommon.  By the 10th or 12th hop, that's a *LOT* of cert chains you have
to walk through to verify (and remember that *each* cert chain is going
to take a chunk of resources)....

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Mar 2003 08:20:05 -0700 (MST)

> From: [email-masked]

> ...

Yes, but that is only because the PKI notion was based on authenticating
strangers despite men-in-the-middle and all other attacks.
To deal with spam, a DNS TXT RR with a public key would be strong enough.

> ...
> it?

Strangers can't be trusted to not be spammers.  Authentication can at
most prove identity.  Contrary to the Verisign PKI whitepapers, the
Microsoft ActiveX promises, and and standard authentication spam defense
claims, authentication says nothing about authorization.

> RFC1413 IDENT, incidentally).

No, my recollection of the original, announced purpose of IDENT/TAP
was to prove that the other guy was not a nasty bad guy.  It was only
well into the TAP/IDENT nastiness that silliness was stomped out. 
I remember arguing for what seemed like eons with people that the
IDENT/TAP token was useless for proving virtue.

> need of running SMTP AUTH to verify that they themselves are the ones

Yes, authentication is not authorization.  We will always need white-
or blacklists, which are nothing more than authorization mechanisms
go to with authentication mechanisms.

These key/token/signing schemes can only address the sender information
that has been "forged" in the sense of willful misrepresentation of identity.
(I'm sorry Paul, but stopping the thread does not resolve the issue.)

> PGP signed - if you want you can validate it via the PGP web-of-trust....

If there is a PKI, you've still got nothing.  Spammers can and must
be allowed to buy certs too.  Authentication is not authorization.
Remember that PGP mantra that the web-of-trust only proves a key
is good and does imply anything about the virtue of the key owner.

> certificates, which prove approximately nothing...

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

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 11 Mar 2003 16:45:48 +0000

> be allowed to buy certs too.  Authentication is not authorization.

With authentication you've got something though - a much stronger 
ability to blacklist.

Matt.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Mar 2003 11:08:28 -0700 (MST)

> From: Matt Sergeant <[email-masked]>

> With authentication you've got something though - a much stronger 

That's wrong, even if you tie email addresses to official government
identities such as U.S. social security numbers.  As I said, Ralsky
and other spammers would never run out of social security numbers with
which to authenticate his spam.  He could pay a "homeless person" to
use certificates based on the person's social security numbers for 2
or 3 weeks of spam.  At the end of 2 or 3 weeks when that certificate
is widely blacklisted, he could hire another "homeless person."  

The only thing that authentication can do is prevent genuine "forgery."
Only if those who claim that the the vast amount of spam that carries
Hotmail, Yahoo, and other free provider sender addresses in
http://www.rhyolite.com/anti-spam/freemail.html is really forged would
authentication by itself have any effect on spam.

Not even if you replace the Internet with a bunch of BBSs by forcing
everyone to send mail from the same domain where they read it would
authentication affect spam.  Have you not noticed that many of the
big spammers have no shortage of officially registers DNS domains with
which they in effect sign all of their spam?

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 11 Mar 2003 19:01:29 +0000

> is widely blacklisted, he could hire another "homeless person."

You're focusing far too much on the perfect here. I said "stronger 
ability to blacklist". Not perfect, but stronger.

Plus I think the above pushes Ralsky (or whoever) into a whole other 
legal bracket than spamming, and thus gives the FTC the teeth they need 
to go after him for federal crime. But IANAL so this may be false.

Matt.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Mar 2003 12:09:51 -0700 (MST)

> ability to blacklist". Not perfect, but stronger.

How does authentication give stronger blacklisting?  Blacklisting
by domain name and IP address works pretty well today.

> to go after him for federal crime. But IANAL so this may be false.

Where's the crime, false advertising, or other naughtiness, besides
wrecking the hopes of people who think authentication is magic pixie dust?
Ralsky would be hiring temporary employees to act as official
representatives of his organization.  I assume he would pay all
appropriate taxes, check citizenship papers, compy with the INS
shoudl during raids, keep records for the FBI and Homeland security,
tell the people he hires the gig is short term, including on his
web pages a description of his operation, and even including in
his spam words like "this message was sent by John Smythe who is
Spam-Al's temporary representative this week."

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 11 Mar 2003 22:39:35 +0000 (GMT)

> by domain name and IP address works pretty well today.

Mandatory auth (and assuming its trustable auth, however that is
implemented) means the spammer can no longer use open proxies (unless he
auths against his own servers via an open proxy) nor open relays. That
means he has to have fixed resources. Yes, the larger spammers can setup
fake ISPs and so on, but they are the minority (in my spam traps) because
this is difficult to do (and *still* results in fixed resources, albeit
with a greater freedom to move around within his slash-space). So at the
end of the day auth buys you a reasonable level of certainty that the user
is who they say they are, which means you can more effectively hit a wider
swathe of the spamming population with your blacklists.

That all requires a huge infrastructure change of course, and I'm not
suggesting it as a solution.

Matt.

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 11 Mar 2003 22:41:16 +0000 (GMT)

> wrecking the hopes of people who think authentication is magic pixie dust?

I believe it would be fraud. Hiding behind hired goons is *not* a valid 
defense against fraud charges.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Mar 2003 15:51:17 -0700 (MST)

> auths against his own servers via an open proxy) nor open relays. 

If you can't get open relays closed, how do you get them to install
mandatory authentication?  If mandatory authentication meant anything
effective, you could use the same magic to say "mandatory no relaying
without SMTP-AUTH" and close all open relays.

Mandatory authentication does not prevent the use of proxies, because
the proxy is transparent.  Any authenticating by the SMTP server will
not be of the proxy's IP address or of one of the IP addresses of a
multi-homed legitimate SMTP client, but of the client itself beyond
any proxies or network interfaces.  If the message carries a good
certificate from the original SMTP client, then it will still carry
a good certificate when sent through a proxy.

All that authentication does is give you another thing to blacklist
in addition to domain names and IP addresses.  The fatal flaw is that
it will be quicker and easier to get new certs than to find IP addresses
of open proxies and at least as easy as getting new domain names.
Worse, you can now test an IP address to see if it is an open proxy
and blacklist it.  Given a cert that has been involved with spam, do
you blacklist it?  If so, why don't you blacklist the domain names and
IP addresses of all big outfits today, because they've all sent spam?

>                                                                   That
> with a greater freedom to move around within his slash-space). 

Spammers will not need to have "fake ISPs" unless you limit the use
of SMTP clients to AOL and other big outfits.  (By the way, what
MUA-MTA protocol do you use?  Are you sure it's not SMTP, making your
system a "fake ISP?")

Are you sure you are recognizing the large spammers in your traps instead
of mistaking them for small fry?

Why won't all spammers still be equally able to use open relays as 
amplifiers of their bandwidth?

>                                                                So at the

If as you say most spammers are small fry that you don't recognize,
then being able to check their authentication won't tell you anything
you don't already know.  You'll not be able to recognize the flood of
new small fry whether by their new user names, domain names, or certs.

  .....

] From: Matt Sergeant <[email-masked]>

] > > Plus I think the above pushes Ralsky (or whoever) into a whole other 
] > > legal bracket than spamming, and thus gives the FTC the teeth they need 
] > > to go after him for federal crime. But IANAL so this may be false.
] > 
] > Where's the crime, false advertising, or other naughtiness, besides
] > wrecking the hopes of people who think authentication is magic pixie dust?
]
] I believe it would be fraud. Hiding behind hired goons is *not* a valid 
] defense against fraud charges.

Where is the fraud?  If there is no fraud, then there's no crime to
hire people to front for you.  If that were a crime, then all corporations
and all U.S. presidents for that last 50 or 100 years would be guilty
because they all have transient "goons" fronting for them.