On Tue, 2005-01-11 at 11:53, Sam Hartman wrote:
Ideally we'd be focusing on getting a charter done and holding off a
bit on the technical discussion until we knew what we were trying to
accomplish.
Each faction has used different design goals and this is where some of
the conflicts seem to exist. Breaking each proposal down to its
components may be a way to judge relative merits and related
complexity. Perhaps this effort will be able to back-out a set of
general guild lines agreeable to a majority of participants. If nothing
else, a technical review may note potential weakness, and this too could
prove helpful. Dave Crocker initiated some of this with his feature
list, but I did not see much feedback.
http://mipassoc.org/mass/
There seems to be no hope of that happening right now, so
I might as well join the technical discussion.
Reading the domainkeys and IIM proposals, I wonder whether we're
focusing too much on security and not enough on deployability.
In a very general fashion, there are a few differences between these two
proposals. One being the resolution of the signature which will affect
the ease of deployment, even if only as an option. By considering just
the domain, the number of potential keys is constrained. It would also
seem including the local part overlaps with other mechanisms and
necessitates additional infrastructure to support this effort. I also
suspect the increase in the possible number of keys led to publishing
fingerprints instead of public-keys. This too seems to be an area that
could be reviewed.
I realize that there was already a recent discussion on this: should
the solution be end-to-end or should it allow intermediaries.
With respect to storage, it is common to overcome a significant loss of
data by providing a type of parity information. This effort is normally
to mask evidence of error. From the standpoint of ensuring old messages
do not become a vehicle for spam, it would seem the acceptable recovery
would delete erroneous data when the original data is recovered, whether
this is using either tagged or copied data. Should added headers then
be left as is?
I'd like to go farther: why are we signing the body? We're trying to
prevent spam not modification of existing mail messages. I think that
canonicalizing headers may be challenging enough; do we really need to
solve the problem of canonicalizing bodies on top of this.
Capture of a signed header would allow attaching a message as a vehicle
to carry spam.
It might be sufficient to sign the recipient, date and message-id (or
some other nonce) and to keep a cache of recently seen signatures.
There would be a sizable dynamic database to support this type of
filtering effort. Some replay should still be allowed. Would this
filter include a hash of the message body? If so, why not have this
done at the sender?
-Doug