--On Friday, January 14, 2005 7:12 AM -0800 Michael Thomas
<mike(_at_)mtcc(_dot_)com> wrote:
James M Galvin writes:
>
> For me, John's last sentence is the most important point in all of
> this discussion:
>
> > The most that a signature can do is to identify the
> > responsible party. There's no point in adding cruft that
> > attempts to go beyond that.
>
> 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?
You are correct, this is one solution, and it's important to keep this
one in mind as we consider other options. But I think we can and should
do more.
I also said in my message that something akin to received lines should
be added to a message. This has been discussed here before but the
point I want to stress is to protect the infrastructure. It's not about
which of the many RFC2822 headers we could/should/want to protect. It's
not even about a mandatory relationship between the SMTP information and
the 2822 headers. For me, it's simply about each hop cryptographically
asserting the envelope information to the next hop, and relating it to
the previous hop to mitigate spoofing and replay.
We might perhaps have a few "codes" so a hop could say explicitly that
it intended to change the envelope information, e.g., list-expansion,
forwarding, relaying, and perhaps others.
All this to be carried in a received-like header. I suppose this is a
layer violation, using 2822 to carry security-relevant information that
is largely from SMTP, but it's the model we have.
With such a system in place a reputation system could be built
separately but on top/along side it. Do we need one in advance? Maybe,
but I'm not yet convinced.
Which is why I think that if MASS solves _any_ problem at all, it
ought to be the end domain to end domain identity problem that
S/MIME and PGP -- with their focus on encryption and end users --
does not easily scale. _That's_ the hole in the protocol suite, not
the edge-edge problem.
And I agree with this but I would like to extend it to cover the domain
to domain to domain, i.e., each hop along the path.
Jim