My PKI plumber comments:
>this totally misses the point of authentication.
>
>what you do in any authentication system, including SMTP, is this:
>
> 1. decide you trust the other person
> 2. issue them enough credentials so they can be identified
> 3. use the credentials in the network
>
>You use the plumbing, like client-side authentication of SMTP with TLS,
>to authenticate that the party with which you are having an SMTP exchange
>is in fact someone you have already decided to trust.
>
>The point is, you only accept SMTP mail from people you
>are willing to accept mail from. And that's going to mean customers,
>trading partners, ISP's who have a guarantee of no spam, etc.
>
>So, the point is >>not<< to prove that foo@fred.yada.info actually
>sent the mail. The point is to assure yourself that the SMTP connection
>you just accepted came from someone you trust (because of the credentials
used)
>and therefore you trust that other party to be someone who's supposed to
>be sending mail labelled "from: foo@fred.yada.info". That might be foo, that
>might be their ISP, their employer, someone you've designated as a spam
>filterer (an ASP -- anti-spam-provider.) Also, the way authentication
systems
>work, you don't blindly trust the address, so the comments below about
>intermediate servers are wrong. You'd only talk to intermediaries you
>trust, like perhaps your ISP with whom you have an SLA that indicates
>an assurance level that they won't forward spam.
>
>
>> >From: Chuq Von Rospach <chuqui@plaidworks.com>
>> >To: J C Lawrence <claw@kanga.nu>
>> >
>> >On 7/7/02 5:41 PM, "J C Lawrence" <claw@kanga.nu> wrote:
>> >
>> >> Yeah, we've been down that road on this list and elsewhere. SMTP/TLS,
>> >> reverse auth, PKI infrastructures, yada yada. A whole lot gets solved
>> >> by providing mutual identity verification/authentication systems for
>> >> distributed systems even outside of mail.
>> >
>> >Does it?
>> >
>> >Assume for a minute that you build a system that allows you verify that a
>> >piece of e-mail's "from" address actually comes from the system it says it
>> >came from? We can simplify it, actually. We only need to verify that
>> >"foo@fred.yada.info" actually came from fred.yada.info.
>> >
>> >What does this actually solve for us? It doesn't solve open-relay issues,
>> >because if you think about it, there's a statistically high chance
that the
>> >machine sending it to you isn't fred.yada.info, thanks to intermediate
>> >servers, dialup sendoff points and secondary MX-relays.
>> >
>> >And it doesn't really solve the ID issue, either. You now have an
>> >authenticated but still opaque token. All it does is guarantee that
someone
>> >who's on your whitelist can't be forged and therefore delivered through a
>> >block.
>> >
>> >So the spammer simply generates a server that when you query it, validates
>> >the signature of the e-mail. You see it, throw that signature into the
>> >blacklist, and move on.
>> >
>> >So does the spammer. His server can simply generate infinite numbers of
>> >never re-used signatures. Or if you attach that signature to a domain and
>> >block it, he generates 10,000 domains, attaches a unique signature to
each,
>> >and it'll take you forever to track them all down and blacklist them, even
>> >collaboratively. You defeat the collaborative aspects by generating
infinite
>> >subdomains randomly, and infinite signatures validating them. And then
when
>> >a given domain gets closed down "enough", the spammer starts over with new
>> >domains, which are trivial to get.
>> >
>> >And all of that is wonderfully authenticated and validated -- and
completely
>> >worthless. In practice, very quickly you turn back to blacklisting through
>> >IP addresses. Which is what we do now...
>> >
>> >One night, a few of us sat down and built a system that took a PKI
>> >infrastructure and built a fully-functional, compliant spammer world
within
>> >it. That's when I stopped worrying about trying to authenticate email. It
>> >ends up solving only a tiny piece of the puzzle (forgeries through
>> >whitelisted addresses), that basically doesn't need to be solved, anyway.
>> >
>> >(Think about this piece of e-mail. It's being sent from my plaidworks
>> >account. But it won't actually touch any machine attached to that server
>> >until list-managers delivers a copy back to me. It'l be accepted by
the SMTP
>> >server of the system that runs the IP network here in my hotel in
Victoria,
>> >and get delivered to you through some magic way.
>> >
>> >If you assume the ability for an e-mail address to "roam", and there's no
>> >practical way to stop that, then there's basically no way to tell the
>> >difference between this piece of email, and a spammer's piece of email
>> >coming to you via some random open relay..... And since either one could
>> >easily have the magic cookie of a PKI or other auth structure attached, a
>> >PKI system doesn't solve the problem of spam email....)
>> >
>> >> Any content that is used to render a message that is also not local to
>> >> the message can be used retro-actively as a web bug.
>> >
>> >[followed by a solid proof why you can't solve this problem with a geek
>> >solution....]
>> >
>> >> A pillory can be a useful and educational thing.
>> >
>> >She is a witch! may we burn her?
>> >
References:
|
|
