[Top] [All Lists]

Re: making mail traceable

2004-01-21 10:50:50

Just for the record, we're in agreement.  I could quibble about some
semantics but that's not productive right now.



On Mon, 19 Jan 2004, Keith Moore wrote:

    Date: Mon, 19 Jan 2004 12:18:14 -0500
    From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
    To: James M Galvin <galvin+ietf-822(_at_)eListX(_dot_)com>
    Cc: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>, ietf-822 
    Subject: Re: making mail traceable

    >>> 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.
    > Agreed.  My point was that the same technology would be used but would
    > be interpreted differently.

    It's going to be very similar technology, but the actual protocol used
    needs to be different.  If submission servers start applying security
    multiparts to messages it's going to break things, and it's going to be

    >> 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.
    > This seems incongruous to me.
    > Some principal is going to assign a hash.  There has to be a principal
    > because the hash has to be digitally signed.  If it's not there's no
    > point having it for the purpose as described.
    > This means the message is at least witnessed and there's
    > non-repudiation
    > to the extent the principal can not deny having handled the message.
    > That is a security measure.

    What I was responding to is the "either you are doing security right or
    you don't do it".  I certainly agree that this should be "done right"
    (to the extent that we can figure out what "right" is) but I think that
    calling this a "security" measure invites confusion between this
    application of security technologies (public-key cryptography,
    noninvertable hash functions) and other applications of those
    technologies, for which "doing it right" means something different than
    it does here.

    > As to whether any of the content is impeachable, that depends on when
    > the hash is actually created.

    It also depends on what is included in the hash.  I believe it will be
    necessary to omit some information from the hash in order to get the
    hash to survive most existing mail transports.  I don't think this is a
    problem as long as we don't treat the originator-id tag as a digital

    >>> I'm sorry but I just don't see what you have in mind that is worse
    >>> than it is today,
    >>     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 [far] 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.)
    > What you say is true but it doesn't refute what I said.  Does this
    > mean you agree with me?

    I still think an Originator-id field would be at least somewhat easier
    for governments to abuse in this way than any of the existing fields.
    Variant use of From is sufficiently widespread that I suspect there
    would be some pushback against the government trying to constrain its