Dave Crocker wrote:
Jim,
There is no requirement that the recipient display the unsigned content
at the end of a message. A verifying MTA may remove the unsigned
content at its discretion.
By having a mass signature apply only to an initial subset of the message
content, we are now faced with a cascading sequence of possible mechanisms that
cause problems or try to get around problems. When we find ourselves starting
to discuss whether some text is, or is not, displayed to the user, as a means
of enforcing a security model, we really do need to step back and look for a
simpler approach.
There are indeed other mechanisms that people might care to propose, and
some hard decisions will need to be made. I continue to believe that a
*modest* effort to allow signatures to survive mailing lists is
worthwhile.
It is bad enough that we are forced to compensate for possible format changes along a path. Having to compensate for basic semantics changes, such as the addition of blocks of text is far beyond the limit of simplicity that a mechanism like this should define.
Clearly your limit and mine are different.
We should make the goal of mass to be validation by a receive-side filter. Any
dependency or expectation of displays to the user -- nevermind concern for
having the user somehow decide whether the message is valid or not -- should be
entirely beyond the scope of this effort.
It isn't clear to me that the manner in which the message is displayed
is really an appropriate topic for a signature specification. However,
in the IIM draft I attempted to codify what should arguably be in a BCP
or something like that about making the source of the signature visible
if it's not the From address of the message.
Here's the attack I'm concerned about: Suppose someone generated a
phishing attack supposedly from Example Bank, security(_at_)example(_dot_)com(_dot_) The
sender of this message registers a domain and attaches a signature from
it, claiming to be a mailing list
(owner-mailinglist(_at_)attackerdomain(_dot_)com). If the recipient gets the
message and just sees that it is signed, the message signature may
actually be helping the attacker by making the message look more real.
If the answer to this is the use of accreditation/reputation systems,
well OK, but that's a much stronger dependency on such systems than I
thought we had. If, on the other hand, someone gets this message and
sees that it was (allegedly) sent by their bank but signed by some
unknown third party, it raises legitimate suspicions.
To summarize: we need to be concerned not only with mailing lists, but
with those who would pose as mailing lists.
> Requiring those that make changes to resign the message does ensure
> this process identifies those accountable. A header could be included
> to allow signature validation to be cascaded.
I agree that it's desirable for those that make changes to re-sign the
message. But I think it's undesirable to say that signatures will just
fail for a large proportion of mailing lists unless that happens.
Why?
Signatures will initially "fail" for nearly all messages, since they won't be
signed. Why should we single out one class of message posters and try to circumvent
their responsibility?
Because there are situations where the mailing list signature is
important (e.g., "I want all messages from the ietf-mailsig mailing
list, regardless of who sent them") and other times when the mailing
list is unknown but the sender is known.
Then there's the other question you touch on, of whether a signature is
added or the original signature is replaced. I'm in the "added" camp
even though that means we have to define how messages are treated when
different signatures succeed and fail.
Again we are faced with the question of value for the added complexity at the
receive side.
We have no history of obtaining successful, widescale use of any signing mechanism for email. That should motivate us to make our current work as simple as possible.
Multiple signatures and rules for interpreting them, guidance for what to
display to recipients, and any other sort of attempt at heuristic robustness
works against the goal of simplicity. It also obfuscates the basic semantics
of the signature, since it confuses who is responsible.
By the way, do we haveconsensus on what the semantics of the signature are?
-Jim