David Woodhouse writes:
On Fri, 2005-01-14 at 07:12 -0800, Michael Thomas wrote:
> So, I ask, why are we trying to do more than find the immediately
> preceding responsible party?
To which I'd say that surely evangelizing TLS for the last
hop out of and into your domain is an easier job than a
completely new protocol?
There is a difference between the two. There's three levels at which we
can attempt to evaluate trust:
First, we could attempt to authorise a given email for its entire
lifetime, through multiple transitions through the mail system and
mailing lists. For this we would use a signature, and hence a
reputation, tied to the address in the From: header. I think this has
been deemed to be too hard for MASS, but GPG and S/MIME attempt it.
I dispute this if we're talking about "good enough" as I
have a fair amount of data showing that our mechanisms get
through a lot of mailing lists and other manglers.
Second, we could attempt to authorise a single transition through the
mail system. We'd use either the RFC2821 MAIL FROM address, or the most
recent RFC2822 sender (From:, Resent-From:, Sender: or Resent-Sender:).
The latter of these is what MASS seems to have settled upon.
Third, we could do only a single hop from one system to another. That's
what IP-based blacklists do, that's what SPF actually achieves, and
that's what CSV does. And that's what the proposed TLS-based system
would do, too.
The thing is that I really don't see what the appreciable
difference is between 2 & 3. The only thing that a signature
would get over a TLS session is that you could put the
signer/verifier n hops back in your infrastructure instead
of being right at the domain border. But how much of a real
world gain is that? I don't get the impression that that's
what's holding up some sort of crypto based solution:
"if only I could put my signer/verifier on the MSA/MDA,
instead of at the border MTA, life would be good..."
It just doesn't ring true. On the other hand, you really,
really, really can't make those kinds of assertions if what
you're trying to assert is the From address through some
arbitrary set of relays -- even if they aren't mangling
relays. There a signature based scheme is the only game in
town.
I quite like the idea of using TLS certificates for authorisation
instead of IP addresses. It may make a useful addition to the CSV-CSA
proposal. Rather than just specifying acceptable IP addresses, we could
also keep the fingerprint of the TLS certificate in DNS too. Does the
KEY RR allow that?
I actually kind of like it too -- more forms of crypto based
identity are better than the status quo of _no_ forms of
crypto identity. But I don't think that MASS needs to
reinvent what we already have an adequate solution for: TLS.
Mike