John Levine wrote:
I can't speak for Dave, but nothing I've seen so far changes my
conclusion that attempts to make signatures survive mailing lists and
other mutations are fundamentally a bad idea. They add vast amounts
of complexity for at most an occasional and transitory, and more
likely an illusory benefit.
I'll agree that it adds complexity, but "vast amounts"? I just don't
see it. As for the transitory nature of the benefit, aren't we often
cautioned never to try to assume the rate at which a new technology is
adopted on the Internet?
As for the "time machine" aspect for all of this, I'm much more
concerned about the little mailing lists that haven't been upgraded in
ages than I am about well-established and well-maintained mailing list
operators. One thing we're trying to do here is to disenfranchise as
few people as possible, even those that aren't professional mailing list
operators.
I don't know all of the ways that list software might mutate a
message, and neither does anyone else. We still don't have anything
close to a concrete proposal to take an IIM signature and a message
and tell us whether the message is close enough to the signature that
we can conclude that the differences are only due to a trip through a
mailing list. And I don't think we ever will, either. Feel free to
prove me wrong, preferably with C code I can run, but I'm not holding
my breath. It's not helpful to tell me that I can use any closeness
metric I want, since I don't know of any usable ones other than exact
match.
This isn't in C, but here is what I would do. The IIM milter
implementation on Sourceforge doesn't do all of this, but we're talking
about what a recipient could do, not what a particular implementation
does at present.
1. Verify the message using the supplied signature, public key, etc. and
verify the validity of the public key. Note that the signature is
calculated using the copied headers in the IIM-SIG header, not the
actual headers in the message. If message doesn't verify, stop here.
2. (optional) Decide whether the body length count on the message
differs from the actual canonicalized length by an excessive amount.
Reject verification if this difference is too large according to local
policy.
3. Replace each of the relevant headers in the message with its copy
from the IIM-SIG header. Yes, this means that you lose the [listname]
annotation that some mailing lists do; some hack could be added for this
but personally I prefer to filter on the Sender address so that private
messages forwarded to me with [listname] in the subject don't get misfiled.
4. (optional) Remove the body text that was added beyond the body length
count.
The experiments I've seen with DK have shown that even rather
simple-looking fuzzy matches can let through heavily mutated messages,
while some common mutations like virus scanner tag lines can be really
hard to deal with. I don't see any reason to think that IIM would be
any different in those regards.
IIM (and DK, with the h: tag) signs specific headers. Virus scanner tag
lines are not a problem, except for DK without the h: tag. I'm not
aware of what fuzzy matches might have been tried.
As far as I'm concerned, there are exactly two kinds of message
forwards. There's the simple dot-forward kind in which the message is
unmodified other than perhaps having a few headers added at the top.
And then there's everything else, mailing lists, MUAs that smash as
they forward, whatever.
I'm aware of quite a few mail forwarders that add virus checking results
at the bottom of the headers, and add tags like [SPAM] or [Suspected
Spam] to the body of the message. My point is that it isn't nearly this
cut-and-dried.
For the first kind, I hope we agree that it's easy to make a signature
scheme work. For the second kind, it's not, so my advice is don't
even try.
That's going to break a lot of corporate mail domains that do virus and
spam checking on the way in.
The whole point of message signatures is to know who's responsible for
the message. For mailing list messages, the responsible party is the
list. You can't tell anything about the quality of a list by checking
internal signatures. A list with no internal signatures might be
manually moderated by someone who calls all the submitters on the
phone to check that the messages are real. A list with 100% internal
signatures could be 100% from dead Nigerian generals.
One attack on this whole thing is for the attacker to pretend to be a
mailing list, and just sign a bunch of spam/phishing messages on behalf
of a throwaway address. The message looks legitimate and signed, but
it's not signed by anyone trustworthy. This puts a very strong
dependency on reputation and accreditation services. And since
signatures are typically going to be checked by an MTA, it's probably
not going to be practical to whitelist all of the mailing lists to which
users subscribe. In such circumstances, if you get a message sent from
a domain you know to be trustworthy, and if it hasn't been munged in a
way that invalidates the original signature (yes, I know it's
technically a signature for a different message) that's something the
recipient can use.
So, please, if you believe that it's useful to have signatures pass
through lists, show us that it works. Show us running code that can
handle mutations from common list managers (try Yahoo Groups, mailman,
listserv, sympa, lyris, and majordomo) but can't be trivially spoofed.
Give us some rules to tell us what we're supposed to do with list mail
that has various combinations of good and bad nested signatures. At
this point, all I see is smoke.
Perhaps this is the "illusory" aspect described above, but IIM
signatures as they are currently defined are surviving a number of
mailing lists, including ASRG, dk-milter-discuss(_at_)sourceforge(_dot_)net,
ietf-mailsig, ietf-mxcomp, and Yahoo! Groups. I typically send plain
text mail to these lists, and there are probably some problems with HTML
messages, messages with S/MIME signatures and the like, but the vast
majority of messages on the mailing lists I subscribe to are plain text
as well.
-Jim