On Wed November 10 2004 21:50, Laird Breyer wrote:
On Nov 10 2004, Bruce Lilly wrote:
No, that would be inaccurate. Message content can be signed
(at the originating endpoint, and the signature verified at the
receiving endpoint) to provide protection against undetected
modification in transit.
The message signature could be illegally removed in transit, and the
body appended with some innocuous sentence such as "P.S. My PGP is
temporarily broken", along with other subtle changes.
That would be a detectable modification, except in a statistically
insignificant number of cases (hash method collisions). It could
be confirmed (as intentional content provided by the sender, or
as a forgery or modification) by an out-of-band method (e.g. a
telephone conversation).
The message could be modified and resigned with another private key
under the purview of the same certificate authority.
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). 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).
You simply cannot claim that message modifications are detectable
without some measure of trust in external entities separate from the
sender and receiver.
Sure I can; modifications are detectable (statistically insignificant
caveat noted above) with zero trust in third parties. It is in
fact blind trust in third parties that may lead to problems. Failure
to trust third parties will never result in failure to detect
modification.
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).
And as I pointed out:
You are assuming an extraordinarily simplistic model which
simply doesn't conform to reality; a model where there are
only "M" and "T" and where each system is either one or the
other, invariant with message content and over time, with no
message transport paths through other mechanisms.
You persist in addressing a non-issue. The sentence preceding the one you
quoted states
I didn't expect this picture to specify a single path from A to
B which must always be used by all messages from A to B, rather it
represents the actual path taken by a given message. "T1" and
"T2" are whatever makes sense for that actual path.
It's an issue because your model assumes that trust is dependent
only upon host name, and is invariant over time and with different
message content, and that it is independent on all other sites that
may be involved in message transport.
My proposition isn't, I don't know which birds you are metaphorically
referring to.
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.
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).
Show me a counterexample
where the intermediate isn't trusted, but the incorrect Processed
payload is still accepted.
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.
Perhaps you would find the following analogy useful: Just as for
cryptographic signing, trust is placed in third party certificate
authorities, here trust is placed in SMTP servers writing Received
lines.
Your analogy fails because when one verifies a certificate, one
knows where one has gone to obtain verification (short of widespread
failure of DNS *and* IP routing); when one looks at a Received
field, one cannot be certain where it was inserted.
In cryptographic signing, certificates can be revoked, and here too trust
in particular SMTP servers can be stopped.
Moot point, 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).
Similarly, if
the Received line's id is "unguessable" (as one example of the
scheme), then a Processed line which quotes this id is very unlikely
to have been written before the associated Received line was written.
Another moot point; both fields can be forged without detection.
You've already noted that sometimes a Received line doesn't contain
an id, and there are difficulties with parsing. Those are good
points, while requiring a recipient to trust an untrustworthy intermediate
just so they can mislead the recipient is not I think.
A recipient may believe that he is using information supplied by
a "trusted intermediate" when in fact he is unknowingly using
forged information. *I* am imposing no requirement for trust;
I am merely pointing out that a bad guy may exploit such
trust (whether the bad guy is the trusted party or a different
party).
Use of multiple filters does not require that any of them be
"remote". Having a local filter and a remote filter does not
guarantee different "strengths" (for any definition of that
rather nebulous term).
Unless, for example, one of the filters has access to a relevant
database which other filters, residing in a different network
location, don't have.
I will concede that from an abstract point of view there may be
a theoretical difference in capabilities, but not that that
necessarily implies *greater* "strength", nor that it is a
*guarantee* of a different "strength". Moreover, as
discussed in a separate message, any hosts capable of
performing meaningful filtering in the context of Internet mail
will necessarily be located in a similar "network location"
from a network topology point of view.
So why again are you opposed to insertion of cruft into the headers by
the list expander?
Because it makes matters worse; it is a "cure" that is worse than
the symptoms. It adds more cruft on top of cruft (spam) and
adds cruft to non-cruft. It exacerbates the problems caused by
spam (wasted transmission bandwidth and storage space).
If imc.org say performs a virus scan and inserts a
header detailing the result, or even changes the subject line by
inserting a label such as [ietf-822], this should be entirely
acceptable from the viewpoint of Internet protocols, since the message
originating from owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org is considered
entirely
independent from the message originating from
blilly(_at_)erols(_dot_)com(_dot_) The
sender of the latter can lay no claim to the contents of the former.
No, the messages are not "entirely independent". The Subject field is
set by the author, and imc.org is not an author in this example, it is
a re-mailer.
Adding cruft isn't "filtering". It makes the problems (transmission
bandwidth and storage capacity requirements) worse. True
corporate filters (as opposed to "filters" that do no filtering) can
and do reduce the problems; but neither they nor any other true
filtering method have any need to add the field that you propose.
I've already given you two examples, the sourceforge mailing list and
a commercial service such as death2spam. Filtering cruft exists.
You haven't demonstrated any need to add cruft. You have simply
shown that cruft can be added, which was already known.