Subject: Re: [Asrg] Email Certification Path Proposal

From: "Alejandro G. Belluscio" <[email-masked]>
Date: Tue, 11 Mar 2003 18:03:21 -0300

> On Mon, 10 Mar 2003 19:06:32 -0300, "Alejandro G. Belluscio" <[email-masked]>  said:
> 
>> 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.
> 
> And my business relationship to you is what, exactly?

Don't mix up things. The business relationships are from a RIR to a
backbone provider, from a backbone provider to an ISP. From an ISP to a
client.

The idea is to use this structure. The price of a Verisign certificate
is a pure monopoly price. Just look at Thawte (50% cheaper) before it
got bought up. Besides, the true cost of emiting a certificate is a
notary problem. So you have to check the documentation (big expense),
certifing the the guy asking you to sign the certificate is actually
entitled by the domain owner to do so (another big expense), watch the
whois database (something like 10 seconds) and pass it through your CA
software (in openssl is about another 10 seconds, with a script it can
be everything atomated). Then you have to run the server, but I think
it's actually much cheaper than what they make you believe. Just look at
the DNS, $35 for years and they have the wholeprice set at $6 by ICANN.
And yet is such a good business that they want to keep it at any cost.

So if your already checked your customer (you're investing thousands in
equipment just to give him service, so you better do it) your cost of
passing through a script his cert is practically nil. Please note that
the SMTP only certifies that the email came from a given account in his
system. So he can take measures against customers who spam or had their
accounts hacked.

Now let's get to the core technicalities because I think I didn't
expressed myself well enough. The RIR are the CA. Those public keys are
to be put into every MTA and MUA that supports this system. Are to be
hosted also by the backbone providers if necessary (little expense
relativelly speaking for eliminating spam). RIRs are notorious for
leving huge fees, so they should be able to host them themselves. So
they sign the backbones providers certificate (which might also put them
on the Internet for checking). Note that the one recieving side might
have to check a revocation list on the RIRs once in a while, but most
clients don't actually check revocations lists. And those backbone
providers keys could be put into the client software too. So the
backbone providers signs the ISP certificate and he uses it to sign the
SMTP certificate. Don't think PGP. Think SSL, but only that if you trust
the first CA then you trust the rest of the chain. Note that all we want
is to know from where this email came. With a certain degree of
security. We are not worried about men-in-the-middle attacks.
The idea is just to be able to know which ISP is not checking well
enough the sending side of spammers. And the backbone provider will have
the same information as the ISP, so if he's not doing his job he can
revocate the certificate. You can also make a blacklist of ISPs if
necesary.

> 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?)

Have you noted that the ones actually running the servers are the one
running the internet? It could be a small cost for backbone providers if
it resulted in the elimination of spam. Besides most of the certificates
would be embedded into the software (and checked once in a while).

> 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.

Do you think so? How is that thawte got bought for ridiculous amounts of
money just to kill the possibility of a true competitor? Why wasn't this
task apointed to the backbone providers so they could charge a fee when
hosting a site? They have all the information about the domain and
company at hand for setting up the account. Besides, the security
requirements are totally different. We want to be able to know from
where the spammers are comming and see if the ISP makes something about
it. If not he'll be punished. You could also make a blacklist of
customers so if you got tagged as spammer with an ISP you won't get SMTP
access with any other ISP.

>> (lots of definitions skipped)
> 
>> 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.
> 
> Reasonable goals..
> 
>> Description
>> 
>> 1. Each SMTP has to enable SMTP-AUTH. This enables the server uniquely
>> 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....

This system is opt-in. You want your SMTP server to be in it you have to
enable SMTP-AUTH, get the certificate from your ISP or backbone provider
and make the SMTP sign the headers of outgoing mails. If you just sign
without SMTP-AUTH and you get a spammer, you're toast, your certificate
will be revocated and the emails of your other client won't go throu. So
you're either a pure spam SMTP (in which case you won't get
certificated) or have an active policy agains it.

>> 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
>> 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.

Yes. Because the the SMTP manager is the one who has to deal with the
spammer. If he doesn't he'll have his certificate revocated. A spamhause
won't get a certificate, or get revoked quite quickly. That's also in
part why we send the the Spam Claim to the signer of the certificate.

>> 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.
> Signed how?  and what makes this more trusted than the set of Received:
> headers?

I've refrained from making specifics about the technical details because
I'm getting input in the idea. But I guess I'll have to be more
specific. The SMTP that actually has the email account (the last SMTP)
add a field to the header with a signature of the the whole mail without
this field. Since his public key is certified by know authority (first
discussion on certificates) then we have a certain degree of confidence
that he actually recieved such email. It can easily be checked if it
originated from the said SMTP by checking his signature.

This are signatures of the whole message and by a checkeable
certification path. Besides, the only idea is to have reasonable
reasurance that siad message was sent by such SMTP and actually recieved
by such other.

> 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)....
I'm not sure the proposed system was explained well enough. The *sender*
SMTP signs the message once. It's certificates is signed by a checkeable
certification path with a to well know authority (the RIRs). Then the
reciever _might_ sign it, too. So what happens in the middle is not
problem. A spammer might try to send an email from a free email
provider. But since the signature includes the To: field he couldn't
resend it from somewhere else make him look like a hop because the
signature wouldn't match the To: field.

Regards,
Alejandro Belluscio

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

---

From: [email-masked]
Date: Tue, 11 Mar 2003 16:26:26 -0500

> part why we send the the Spam Claim to the signer of the certificate.

Of course, if the SMTP manager is on the payroll of the spammer, and is
the signer of the certificate, they can just drop the Spam Claim on the
floor.

"A spamhaus won't get a certificate or get revoked quite quickly".  Why is
there a spam problem, when spamming is against the official AUP at most ISPs?
After all - nobody would sell bandwidth to a spammer, or if they did, they'd
revoke it quickly, right?

So let's see - there exist shady ISPs that will sell bandwidth to spammers,
even though other sites may blackhole their entire AS (remember - the MAPS
RBL is available as a BGP feed, and used at some sites).  But you don't expect
there to be any shady certificate issuers that will issue certs to spammers,
even though other sites may refuse to honor anything signed by them.

All you're doing is changing the problem from whack-a-mole bandwidth to
whack-a-mole certs.  And that's even worse - the telco can take weeks to
deliver a DSL or T-1 to a new base of operations, but a new cert can be
delivered in minutes.  Of course, the really serious spammers are either not
worried because they've paid off the ISP, or they've already got replacement
lines/certs/whatever already in process for the next spamming run....

---

From: "Alejandro G. Belluscio" <[email-masked]>
Date: Tue, 11 Mar 2003 19:01:21 -0300

Hello Valdis,

Tuesday, March 11, 2003, 6:26:26 PM, you wrote:

VKve> On Tue, 11 Mar 2003 18:03:21 -0300, "Alejandro G. Belluscio" <[email-masked]>  said:
>> spammer. If he doesn't he'll have his certificate revocated. A
>> spamhause won't get a certificate, or get revoked quite quickly.
>> That's also in part why we send the the Spam Claim to the signer of
>> the certificate.

VKve> Of course, if the SMTP manager is on the payroll of the spammer,
VKve> and is the signer of the certificate, they can just drop the Spam
VKve> Claim on the floor.

The signer should be a backbone provider. If we can't count on them for
stopping spam, then we will need a huge different an quite more
complicated solution. Anyway, loosing the possibility of offering SMTP
for a backbone provider and of signing its the certs of its ISP
customers is a huge economical detterrent. Unless a backbone provider is
dedicated entirely to spam. In which case chould be easy to block :-)

VKve> "A spamhaus won't get a certificate or get revoked quite quickly".
VKve> Why is there a spam problem, when spamming is against the official
VKve> AUP at most ISPs? After all - nobody would sell bandwidth to a
VKve> spammer, or if they did, they'd revoke it quickly, right?

That's why this is a multitiered architecture. With backbone providers
having their a very strong business incentive not to let it's own
certificate get revocated. Besides, even though is against AUP most of
the administrators are too lazy or unskilled to handle the spam problem.
Just watch how man MS SQL got owned monthes after the patch was issued.
Or how many unpatched Apaches are out there.
You have to admit that you have to change the incentive of the ISP so
the actually block spam. This is a way.

VKve> So let's see - there exist shady ISPs that will sell bandwidth to
VKve> spammers, even though other sites may blackhole their entire AS
VKve> (remember - the MAPS RBL is available as a BGP feed, and used at
VKve> some sites). But you don't expect there to be any shady
VKve> certificate issuers that will issue certs to spammers, even though
VKve> other sites may refuse to honor anything signed by them.

MAPS its not a semicompulsory standard. I stated very clearly that this
system needs to be implemented "pervasivly" to be truly useful. Besides,
remember that there are at least three signers plus the SMTP user. And
it gets up to the RIRs. So if you have a shady RIR that goes along with
spammers... then you have a different set of problems since I hardly
believe there's a solution that doesn't depends on some authority doing
its job well enough.

VKve> All you're doing is changing the problem from whack-a-mole
VKve> bandwidth to whack-a-mole certs. And that's even worse - the telco
VKve> can take weeks to deliver a DSL or T-1 to a new base of
VKve> operations, but a new cert can be delivered in minutes. Of course,
VKve> the really serious spammers are either not worried because they've
VKve> paid off the ISP, or they've already got replacement
VKve> lines/certs/whatever already in process for the next spamming
VKve> run....

If this system is universal (a big if, I've admited), then paying off
it's not so easy. Specially because if some ISP gets shady they get
revoked. So the should base their whole business on spamming. If you
make some compulsory rules to backbone providers to be able to provide
ISPs service, like giving a 30 day certificate for the first six months
and watching very carfully if they accept spam, then making a new ISP
each time they get whacked is real expensive. I know, you'll say that
backbone providers will be bought off. Let the competence accuse them
and have its cert revoked. I don't think any backbone provider will want
that. And we are depending on the greed of the competition to tip them
off. So the more cutthroat competition between backbone providers, the
better.