Re: preventing header tag spoofing without crypto

David Nicol wrote:
> I like the idea of including a time stamp in a Tagged: header
> 
> I prefer discouraging rearranging the Tagged and Received headers
> over declaring that Tagged headers are supposed to copy time stamps
> from Received headers.

I'd love to be able to say "No authentication is needed, because ordering is 
guaranteed." However, ordering is not guaranteed in the transport system, 
which is relevant in at least one not-uncommon case:
Bob has an address, [email protected]. The MX for ieee.org scans and tags 
messages and then forwards them on to [email protected]. In transit between 
ieee.org and other-isp.net, the headers get rearranged. After that, only the 
headers added by other-isp.net mail servers are usable to Bob, because there 
is no way to verify the ieee.org headers unless they have some 
authenticating information included. Despite the fact the Bob trusts IEEE 
servers to process his mail appropriately, he has no way to make use of that 
processing work.

It is certainly a good idea to discourage any rearrangement of headers in 
the mail transport system, if for nothing but efficiency of processing in 
the simple case in which everything remains in order. However, we cannot in 
any way depend on this behaviour for our proposed header to be useful.

> There is a lot of information in Received headers.  A human being can
> easily do sane path verification by reading Received headers.  I suppose
> the various path verification proposals are attempting to automate this,
> but that discussion is off topic for discussion of the Tagged: header.
> 
> I think it makes sense to leave it positional, just like the received
> header.  From an implementation viewpoint, it is easy to leave them
> alone.  Write your tags, then write the file just like you got it.
> Received is prepended when a message arrives.  Maybe Tagged would get
> prepended as a message leaves, so it could be above Received in the
> headers.  Above or below, it doesn't matter, but next to the Received
> header will remove the risk of spoofing.   The fake tags would be
> farther in than we are expecting them. The first tags will be closer to
> you.  Fake tags will be under the real tags.  So what if all the garbage
> gets tagged "not-garbage" when it is sent, the garbage detector will
> detect and retag.  The tag checker starts at the beginning of the
> message and trusts the first garbage/not-garbage tag it sees, as that
> will be the one applied by the last garbage detector that the message
> passed through.
> 
> Grouping the tagged headers together in a different part of the message
> and then having to match them up based on identifying a time-stamp seems
> to me like a contrived alternative.

Ideally, they will remain exactly in the order they were added, interleaved 
with Received headers. The time-stamp is just a low-cost protective measure 
that prevents spoofing and allows guaranteed ordering.

> Adding headers at the beginning of the message and leaving the
> rest of the message alone is very easy to do.  Matching lines up based
> on fields in them is tricky.  The only advantage I see in it is that it
> would raise the implementation comlpexity of standard compliance, and I
> do not consider than an advantage, speaking as a lone implementor.

The recommendation of this group will be one of immediately preceding or 
immediately following the matching Received header. As you state, there is 
no positive reason for any placement but adjacent to the appropriate 
Received header. We are simply making provisions for the possibility that 
headers will be rearranged, while keeping the cost to process even 
pessimally disordered headers at a minimum.

Again, assuming nothing about header ordering, even of Received headers 
(which is a potential implementation breakage that may exist in some 
systems), is there a cheaper way to authenticate where and when tag header 
was added?

Philip Miller