Re: preventing header tag spoofing without crypto

Laird Breyer wrote:
> [snip background]
> When a filter adds a tag T, it includes the specific date written in
> the latest Received: line, as a form of authentication
> information. This way, the tag T can be placed anywhere in the header.

I think this is an excellent idea.

> If a spammer wanted to create a spoofed tag T, he would have to
> predict the exact time which will be inserted in the Received: header by a
> later MTA. (To make this absolutely impossible to predict, it may be
> necessary to require MTAs to include the millisecond in the Received:
> line, which the spammer would definitely not be able to predict.)
> 
> The advantage of this kind of authentication compared with say secret
> passwords is this: the time inserted in Received: is a "public"
> password, which doesn't need to be managed within an authentication
> framework at all. Anyone can verify a message, at any time, even years
> after the transport occurred, on a completely different system. 
> 
> Spammers are always on the wrong side, timewise, of the Received:
> line, so they can never predict the date sufficiently accurately. 
> Even better, there is no secret which can be compromised. Even if the
> spammer hacks your system and views every single delivered message, 
> he can't use any information to improve his chances of spoofing a tag
> T correctly in the future. 

Well, you could talk about timing attacks on the observed delay between 
transmission and addition of the Received header, but that's unlikely and 
very easy to defeat. I think this risk can be safely ignored, although we 
may wish to record it somewhere.
Compared to a cryptosystem, this is a major improvement.

> Ok, this is the basic idea. Now let's criticise/modify it.

I have just one suggestion:
The received-matching timestamp should be separate from the timestamp that 
the filter records as when it the filtering took place, if it records that.
In other words, we should have keys 'received-time' and 'tagged-time' or 
similar, to distinguish between the authentication time and the processing time.

Philip Miller