On Nov 13 2004, Bruce Lilly wrote:
Arguing that an intermediate may exist which is trusted by the
recipient but, whether intentionally or otherwise, doesn't deserve
this trust, is not very profound. So what?
So the recipient trusts what is purported to be claimed by that
site! To return to your very simplistic model:
A -> M1 -> M2 -> M3 -> ... -> T1 -> T2 -> ... -> B
Site M3 can forge a Received field and corresponding "processed"
field asserting insertion at T1, then bypass T1 by sending to T2
(using a source route, using non-SMTP transport, etc.). The
recipient has no way of determining what has happened, and
trusts what M3 has inserted (which purports to be from T1).
Per your model and the scenario above, M3 is in your "untrusted"
category, but the "incorrect" fields inserted by it are trusted.
Q.E.D.
Well done, now we're getting somewhere! Source routing is very
interesting. If T2 is located on a LAN, would this require an open
relay or is this not needed? Also, can the very last SMTP server which
accepts the message on behalf of B be forced to *not* insert its own
Received line?
[...] because one cannot determine which content is inserted
by any particular SMTP server (short of wrapping and signing at
each stage during transport as suggested earlier in this discussion).
I must admit that I was under the impression that at least that case
is guaranteed to be unforgeable (ie if the message was transported
through SMTP and none of the subsequent MDAs alter the message
headers, then at least one Received line exists and the top Received
line was written by the last SMTP server along the path).
I'll respond to your other very interesting message separately, below
are just some minor points.
You're assuming a particular model which is not applicable to
all signatures (it may apply to S/MIME, but not to PGP/MIME,
since PGP/MIME does not use certificates).
Even a "web of trust" alternative as used by PGP must still be trusted on
arbitrary grounds, and compared to a hierarchical system it's more
difficult for the web of trust to scale as I understand it.
Moreover if one
receives a message purporting to be from the XYZ company
but which is signed by a key associated with Joe Spammer, the
fact of that mismatch indicates that something is awry (it
might be due to modification in transit, or due to a forgery at
the source).
Out of band verification such as with the telephone won't work unless
there's already an out of band relationship to start with. If all you
have is information within the message, you can't verify much.
Requiring an existing relationship means this type of verification is
not scalable to the internet, as much email communication also
initiates new relationships.
I'm saying that people may elect to trust certain mail transport
agents. There's no difference between that and electing to trust
VeriSign say.
Perhaps true, but irrelevant (except for the fact that such trust
may lead to problems in either case).
You're arguing from the classic risk averse point of view. Other
points of view are risk neutral and risk seeking, in which the
potential problems are outweighed by other perceived benefits.
Your proposition as stated is "we always have a model of message
transport as follows: [...] M represents computers which are
untrusted by B, and T represents computers which are trusted by B",
i.e. that all hosts involved in message transport are either always
"T" (regardless of message content, invariant over time) or
always "M"; it has no provision for degree of trust (as opposed
to a binary "trusted"/"untrusted" distinction) -- it is a black-and-white
model that has no provision for any shades of gray or other colors.
I don't see that. Since trust is entirely a quality originating from
B, the amount of trust attributed to "T" (by B obviously) can be any
shade of gray as well as dependent on time or message content, once B
gets to see the message and analyse it. Of course, B probably applies
simple heuristics wherein "T" is trusted regardless of content or time
of day as you claim, but it's not a necessity.
--
Laird Breyer.