ietf-mailsig
[Top] [All Lists]

Re: Web pages for MASS effort

2004-12-05 22:08:14


On Dec 4, 2004, at 10:27 AM, 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.

I don't know how to build a signature mechanism that self-destructs when it goes through a mailing list, unless we do something based on SPF or BATV or SES.

If it's possible to build a signature that self-destructs when it goes through a mailing list or is remail-'d by a human, tell us about it.

If it's not possible to build a signature that self-destructs, I don't know how you propose skipping a discussion of what's supposed to happen when multiple signatures occur in a message and 'something' needs to interpret the meaning of those multiple signatures. That 'something' could be the MUA, the MASS-aware MTA that's adding SpamAssassin-like headers to the message, a human, or other machanism.

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.

If you want the signature to not survive having text added ("to unsubscribe, email me"), that's one requirement. If you want the signature to not survive a mailing list, that's an additional requirement. You're combining the two in your argument against the current DK/IIM approach; I'm not sure why you're combining them.

Are you wanting an SPF/BATV/SES-like approach for MASS's signature?

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.


Umkay.



 >  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?

Why? Because two users who otherwise are signing and validating their messages can't control an intermediate third party's mailing list which isn't signing its own outgoing messages. In such cases, you seem to prefer that the original poster's signature self destruct -- that is, be unavailable to the receiver at all.


  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.


-d

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
www.brandenburg.com




<Prev in Thread] Current Thread [Next in Thread>