On Sun, 18 Jan 2004, Keith Moore wrote:
>> 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.
>> - 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
>> where
>> 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.
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.
As to whether any of the content is impeachable, that depends on when
the hash is actually created. Certainly if it's created after a "Date:"
is added or after the local "Received:" is added, then those fields are
impeachable. Presumably the rest of the content is opaque to the
creation of the hash so it's content may not be impeachable against the
principal, but with the Date: field you've got a security service.
Did you have something different in mind?
>> 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?
Jim