Great Circle Associates List-Managers
(July 2002)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Trust/authentication mechanism for SMTP
From: JC Dill <inet-list @ vo . cnchost . com>
Date: Mon, 08 Jul 2002 21:11:19 -0700
To: <list-managers @ greatcircle . com>
In-reply-to: <B94E33D3 . 46C6F%chuqui @ plaidworks . com>
References: <6185 . 1026088905 @ kanga . nu>

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:
Indexed By Date Previous: Re: about Netscape, about subject lines
From: "Roger B.A. Klorese" <rogerk @ queernet . org>
Next: Re: Please prune this list!
From: Nick Simicich <njs @ scifi . squawk . com>
Indexed By Thread Previous: Re: OT? browsers or other viewers (was Re: The role of the mailing list)
From: J C Lawrence <claw @ kanga . nu>
Next: HTML is a programming language.
From: Nick Simicich <njs @ scifi . squawk . com>

Google
 
Search Internet Search www.greatcircle.com