On Mon, 10 Mar 2003 19:06:32 -0300, "Alejandro G. Belluscio"
<baldusi(_at_)uol(_dot_)com(_dot_)ar> 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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg