[Top] [All Lists]

Re: making mail traceable

2004-01-17 23:08:09

Doesn't RFC1847 (security multiparts) already provide both of these, or
at least the framework sans the actual algorithm?

    Only if everyone's user agents treated a security multipart
    containing a message semantically the same as they would the
    original message.

Sure, so your primary concern is that the use of security multiparts
would be a less backwards compatible change than a change to the
Received syntax or adding a new header.

That, and there is a semantic difference between a signed message and a cryptographically verifiable trace field in a message.

    - A way to ensure that messages get tagged with originator-id when
    are injected into the mail systems

I agree in principle, I think. But couldn't a Received already provide this information if everyone would just do it, i.e., it's optional now?

The two are fairly different. You want to capture the originator-id at submission time, not at every hop. And you need protocol elements that
    Received (not being extensible) cannot convey.  To me it makes more
    sense to start from whole cloth.

I agree with the principle.  As to whether it's in a Received header or
in something different I also agree with Dave Crocker's point that we
really need to examine what we want to capture before we can know for
sure where to put it.

Fine with me. In general I agree with the approach that you decide what the data model should be before you pick the presentation layer. (wish more IETF efforts would do the same...)

    - If you really wanted to, you could augment Received or add a new
    trace field that recomputed the hash at each hop (to show if and
    the message was corrupted in transport)

Why would you forward a message that was discovered to be corrupted?

Probably because the message might have been corrupted in a way that
    makes the hash invalid without actually changing the content of the
    message.  Something tells me it will be difficult to write a
canonicalization function that accommodates all of the various kinds of
    message and header munging that is out there.

I can imagine it might be a local policy preference for all messages to
be examined by a person instead of rejecting it if the hash validation
fails.  However, it should be the case that except for human review the
message is rejected (for whatever we decide rejection means). There may
be some edge cases where broken mailers do really obscure things to
messages to break the hash, but either you are doing security right or
you don't do it.

Actually I don't see this as a security measure. It doesn't really protect systems from any kind of attack, and it doesn't authenticate the message as being authored or witnessed by any publicly known principal name. It doesn't even have to provide an unimpeachable assurance of non-repudiation -- it just has to be good enough that it's infeasible to make large quantities of spam look as if it were associated with originator-ids other than those controlled by the spammers.

I'm sorry but I just don't see what you have in mind that is worse than
it is today,

Given the apparent aspirations of the current occupant of the US White
    House, things could get far, far worse than they are now.  I'd far
    rather have spammers than Big Brother George any day.

Can you please elaborate on the "mass surveillance" you fear?

    Have you read the Patriot Act lately?

Okay, I'll be more specific. If every message has an originator-id tag that can be traced to the origin, it becomes fairly simple for the US Government to insist that all US ISPs (and perhaps, all foreign ISPs peering with US ISPs) give them a list of mappings from tags to more
    recognizable identifiers (such as credit card #s), or that the ISPs
    generate tags in such a way that the USG can simply decrypt them to
    obtain those identifiers.  Given the kind of stuff that is already
    authorized by existing laws, (and if not authorized, obtained by
coercion of various kinds) this isn't much of a stretch. And everybody
    knows that terrorists use email...

Anyway, the reason my proposal allows originator-ids to be ephemeral is
    to make it hard for ordinary people to track messages - I believe
    anonymous speech is important - and also out of recognition that
    spammers can probably get ephemeral accounts anyway.

My point is that we are not that from this already.  To stretch the
example to the extreme, the US Government could make a law that ISPs
have to make sure they can map a From: email address to an actual person
before accepting submission of a message (in the US of course).  Why do
we need a special identifier?

The US Congress might or might not care, but for a variety of reasons it would not be appropriate to use From in this way. There is no defined header field that can be used for this purpose without conflicting with valid and existing uses of the field. (Sender would have been the right thing, but it's too widely misused now.)

And as you suggest, anonymity is achieved by using a throw-away account
with one of the free providers. We just need to know that we can filter
on such origins if we don't want "trust" or otherwise want them.