On Dec 5, 2004, at 10:57 PM, Dave Crocker wrote:
> 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,
Actually, what is being discussed is an attempt to negate the
self-destruction that *does* happen. The semantic modifications
performed by some/many mailing lists destroy the validity of the
signature.
Destroying the validity of a signature is different from destroying the
signature itself.
IIM and DK are trying to maintain the validity of a signature through
today's mail infrastructure, including mailing lists (as you know). I
thought you were arguing against that feature, and wanted a way for the
signature to purposefully become invalid or destroyed, which is
different from a mailing list's normal operations making the signature
invalid. I'm sorry for my misunderstanding.
Still, I can't figure out where you came up with the self-destruct
issue or how it relates to the discussion.
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
Multiple signatures mean that a new signature creature does not remove
old ones. We can do something about that in the spec, just as we can
specify that a 'validated' header should be removed when the message
leaves the administrative trust domain.
Okay, great.
> 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
What is the limit of modifications that are to be compensated for?
Why? What justifies "compensating" for any semantic modification to
the message?
By stashing the headers into IIM headers, the original headers can be
restored and displayed to the user. So we can actually back out some
of the modifications common in today's mailing lists --- without
requiring upgrading those mailing lists.
I realize the other side of the fence is the crowd of people with the
'upgrade your mailing list to sign messages' signs.
What about the security hole this leaves, permitting spam to be
appended to the message?
If the mailing list signs its outgoing messages, and the only signature
that's important is the mailing list's signature, and that signature is
valid, then data was appended by the mailing list and it's good data,
right?
So the value of the message-length, and perhaps some of the
header-stashing is short lived -- that is, until mailing lists behave
correctly and begin signing messages, and until users trust mailing
list policies to be as strict or lenient as their own policies.
Are you wanting an SPF/BATV/SES-like approach for MASS's signature?
I do not understand what you are referring to.
> 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.
This puts forward a model of the mailing list as merely a misbehaving
relay. It is more than that.
It modifies the original message and posts a new one.
Yes, and I expect the new message can be as tracable to the original
poster as the message the poster sent to the mailing list. Even in the
case of someone with a mail user agent that adds remail-* headers, I
expect I should still be able to authenticate the message (*).
((*) provided it's within 4 or so days of its original transmission, as
I don't expect MASS to want to handle time beyond typical SMTP retry
limits.)
-d
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com