On Wed, 2004-10-27 at 22:55 -0700, Jim Fenton wrote:
At 10:54 PM 10/27/2004 +0100, Tony Finch wrote:
In the short run, requiring that mailing lists do this in order for
verification to work is a serious deployment problem.
It will take some amount of time for mailing lists to begin checking
signatures and signing; if that's too long people may give up on
message signatures.
I'll hazard a guess that it'll take them about as long to do this as it
has taken (or should that be 'is taking'?) them to deploy ESMTP. Let's
not be overly optimistic about this.
A 'solution' which requires the world to upgrade is going to be dead in
the water. Let us not make that mistake.
We should make some attempt to get message signing to work with at
least some mailing lists to make it more effective before the lists
upgrade. IIM has two mechanisms for this: Body Length Count (so a
footer can be appended to the message) and header copying (so we can
deal with modified subject lines, for example). These are based on
our observations of common list behaviors.
In that case, surely William's comparison matrix is inaccurate? It says:
"Signature is not affected if additional text is added to email body"
IIM: "No (signature would not verify)".
Due in part to my lack of time, I'd discarded IIM as a serious proposal
for that reason alone, and hadn't read the draft in detail. Surviving
mailing lists is one of the _most_ important criteria in my opinion.
I'll try to find some time to read it now.
On the other hand it's also a fundamental requirement that a scheme
should have a way to advertise to the world that all mail from a given
address will be signed. Without that you can't just reject unsigned mail
up-front. And according to William's table, IIM lacks that too.
We are not trying to make every mailing list work without modification to
re-sign. But making some lists work through simple mechanisms like this
seems like a small amount of effort well spent.
Yeah -- making _every_ mailing list work would be an impossible task.
But most mailing lists don't do much to the mail as it passes through,
and what they do normally do is easy enough to deal with. It would be
negligent for us not to bother, for no better reason than "oh, the
complexity of it".
There's no inherent reason that a message shouldn't have signatures both
from the original sender and the mailing list resender, or either, or
neither.
I agree, but this is a different issue entirely. In the absence of
mailing lists that re-sign, the original sender signature will be the
only one available.
Why so? I see lots of mail with both From: and Resent-From: headers, and
why should I not want to verify that the author really did write the
message?
I consider a valid signature that is based on the 2822 From address to
be more valuable than another one applied later because it signs the
address that I will be looking at in my MUA; also it's a more end-to-
end assertion.
That's true -- I agree. My point was that there's a trade-off to be had.
We can have something really simple, or we can accept a modicum more
complexity in order to make it more useful.
We do have to be aware that some MUAs won't actually display the address
in the From: header either, mind you -- but users of really broken MUAs
are always going to have problems.
I want to make sure that an attacker isn't forging a message and
then signing it on behalf of a non-existent mailing list in a
throwaway domain. If I accept messages that are signed but from
unknown parties, this might otherwise be possible.
I want that too. That's why I want my own signature on a mail to survive
even if a mailing list resends it and signs it for itself, or if someone
else resubmits it with Resent-* headers to the mail system.
But others are interested in white-listing the address of the mailing
list itself. Taken with the previous paragraph, perhaps that is an
argument for multiple signatures.
I don't think white-listing mailing lists works that well in practice.
It just doesn't scale to large organisations who want to use this to
reject mail at SMTP time.
Multiple signatures really aren't hard to do. It's _not_ that complex.
Let's not strive for simplicity at the cost of useful functionality.
--
dwmw2