From: David Woodhouse
Sent: Sunday, September 19, 2004 3:00 AM
On Sat, 2004-09-18 at 23:58 -0500, Seth Goodman wrote:
Mailing lists have to resend it as their own outgoing message
anyway.
<...>
I disagree. That reduces it to a hop-by-hop scheme again. In order to
determine the probability that this message really did come from me,
you'd have to ponder how much you trust the list server to have actually
checked.
Technically, you are of course correct. For the particular case of mailing
lists, I never considered it terribly important to have strong validation of
originating identity. It's just list traffic, after all. It's in the
list's interest to do this authentication of incoming posts to keep out
spam, but you're right, as users we don't really know what goes on. Maybe
it's just me, but I don't think of list traffic in the same way as my
personal inbox. If someone feels that it is really important to protect
their identity on a list, they can always use in-line PGP, ugly though it
is, as it survives pre-pending and post-pending of lines.
The idea that all MUA's would have to change to deal with displaying
multiple signed parts in different colors, as well as noting parts whose
signature doesn't validate does not bode well for adoption.
That's a purely optional optimisation. If any scheme _required_ such a
thing to be implemented by all recipients, the scheme would of course be
doomed.
I knew you felt that way, I was playing devil's advocate. Since no MUA
today would know how to deal with the multiple signatures anyway, it would
have to be an MTA process and the message would either be accepted or
rejected. The end user would have no way of knowing who signed what, only
that the MTA figured out that everything was legitimate. My questions is
how valuable are the multiple signatures if the end user has no way of
knowing who really added and signed what parts? You could have four people
that signed a message, and the _text_ signatures have no relation to the
crypto signatures. For example, Bob could add a few lines of text to
Shirley's message disguised as a P.S. from her and sign it with his key
(nasty bugger that Bob), but the recipient wouldn't know that P.S. came from
Bob, not Shirley, even though the MTA validated both signatures.
I suggest we don't have to allow additions at all, in any of
the MIME parts.
<...>
Now you sound like the SPF folks declaring forwarding to be 'poor
practice' or 'forgery'. Let us not consider it 'poor practice'; let us
consider it 'current practice'.
You really know how to hurt a guy. Of course I don't have anything against
forwarding. I _do_ have a beef with anyone who changes message content, as
opposed to headers, in transit. Since I've never used any of the free
services, I am unaware of forwarders that actually change message content.
While I am aware that junk is often added at both ends of the link, I was
unaware of forwarders who actually do that. If that's what current practice
is, I believe you. Can S/MIME or the attachment signature of PGP survive
this kind of mangling? I would guess not.
And in the case of mailing lists it's a practice that some will defend
robustly. I _like_ having unsubscription instructions on every mail
which is sent to my lists. People are in general too stupid for me to
omit that.
Most people appreciate that convenience and not having to look at "how do I
unsubscribe" messages. Mailing lists are a special case since they have to
re-mail all the posts such that bounces go to them. They are the message
originator as far as the email system is concerned, even though they are not
from the user's perspective. What you are proposing is an interesting idea
that effectively accomplishes what in-line PGP signatures do but is somewhat
more opaque, unless your MUA does the fancy highlighting. I still don't
think it is important to have that level of authentication on mailing lists,
but that's a personal opinion. The more important question is the potential
for mischief, as in my example above, when the end user can't see who added
and signed what part as they can with in-line PGP.
I'm not arguing to use in-line PGP, as that is awful to look at. What I am
observing is that your scheme cries out for some MUA assistance to show the
user what happened, and it may not be usable without it. Maybe you could do
something along the lines of in-line PGP where there are visible separators
that delimit the signed parts, but all the crypto stuff for them is hidden
in the headers. You'd have to make sure it was a uniform separator that
people would always recognize, not something that could be turned into
white-on-white in HTML. The aesthetics could be improved, but here's what I
mean:
Resent-From:<Bob(_dot_)future(_dot_)ex-employee(_at_)acme(_dot_)com>
Resent-To:<all-employees>
Resent-Date: Friday 17 Sept 2004 13:00:00 -0500
Resent-Message-ID:<asdioewiahejahdiaheawehfu>
X-Resent-Sig: "bob is a blob", "zq1DeP7"
From:<Shirley(_dot_)the(_dot_)boss(_at_)acme(_dot_)com>
To:<department-managers>
Date: Friday 17 Sept 2004 12:30:00 -0500
Message-ID:<ioweijw4fihgaisjjepoeijf>
X-Sig: "shirley eats tires", "XqgTu4"
<XqgTu4>
*** Start Shirley(_dot_)the(_dot_)boss(_at_)acme(_dot_)com Signed Part ***
To all managers,
Times are bad and we're broke. Everyone
has to work Saturday from now on for no
pay. Don't even think about complaining.
Shirley
*** End Shirley(_dot_)the(_dot_)boss(_at_)acme(_dot_)com Signed Part ***
</XqgTu4>
<zq1DeP7>
*** Start Bob(_dot_)future(_dot_)ex-employee(_at_)acme(_dot_)com Signed Part ***
P.S. On second thought, money isn't everything.
Life is too short. Forget what I said and give
everyone every Friday afternoon off with pay.
Shirley
*** End Bob(_dot_)future(_dot_)ex-employee(_at_)acme(_dot_)com Signed Part ***
</zq1DeP7>
--
Seth Goodman