Re: preventing header tag spoofing without crypto

On Mar 29 2004, David Nicol wrote:
> 
> I like the idea of including a time stamp in a Tagged: header

I sort of like it too. It's a nice logging mechanism and probably quite
valuable for debugging. 

However, in terms trusting tags, I just want to make clear it's
useless. Any spammer can simply make up a time moderately in the
future and stamp his fake tags. For example, it would be trivial to
write a SMTP client which checks the current time right when the
message is accepted, and adds a random number of minutes/seconds to
his fake tag. Given the current lack of standards for tag ordering,
this means nobody can trust such tags on the basis of their own
timestamp. 

> 
> I prefer discouraging rearranging the Tagged and Received headers
> over declaring that Tagged headers are supposed to copy time stamps
> from Received headers.
> 

As a long term goal, this would be simple and clean. In the short
term, what sort of adoption rate could we expect? The trouble is that
a system which prohibits rearranging needs to be end-to-end, and if an
intervening agent still rearranges the headers, you can no longer
trust any of them.

> 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.

I think one half of this is a good idea. However, if you place the
Tagged header below the Received line, it's trivially
spoofable. Here's a scenario:

spammer's client connects to SMTP server, sends a message whose first
line is Tagged: (spoofed tag). SMTP server adds Received: right above
it, and maybe sandwiches another Tagged: below it. Now the next agent
after the SMTP server is done doesn't know if there were two legitimate
Tagged:, a single legitimate, or no legitimate (in case SMTP server
doesn't add Tagged:).

The only viable way is to always add Tagged: above Received:, with no
exceptions allowed.


> 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.  

You still need an authoritative dividing line between the real tags
and the fake tags. Without such a dividing line, you can't distinguish
a fake from a real (unless you introduce crypto authentication, which
this thread is exploring if we can get away from). The Received: line
is a fully functional dividing line, provided headers aren't
rearranged around it.

> 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

The trust issue is needed for filter cooperation. If right behind your
SMTP server, there's a bogofilter, and a SpamAssassin, how do you know
which one is fake? More importantly, if yet another filter wants to
use their recommendations, how does it know they aren't fake, given
that it doesn't necessarily know which filters to expect upstream?

> 
> 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.
> 

It's contrived for a good reason. As I said above, a timestamp introduced
by the tag, marking when it got added, is trivially spoofable. 

The timestamp added by the SMTP server isn't, because the spammer
can't predict the exact time in the Received: (certainly, if the
timestamp were to include milliseconds, it would be practically
impossible. With seconds or minutes, there would be a small chance for
the spammer to fake it).

Other quantities in the Received: line would be spoofable, if the
spammer gets hold of sample emails from the target domain. For
example, the names and addresses of the SMTP servers along the way
could be faked by the spammers, so those names aren't trustable
identifying information.

> 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 implementatino comlpexity of standard compliance, and I
> do not consider than an advantage, speaking as a lone implementor.
> 

You've got another good point. But you'd have to weigh the complexity
of such a scheme with the complexity of some other authentication
scheme which could allow filter cooperation. Perhaps someone on this
list knows a lightweight crypto system which could compete with the
present scheme?

BTW, there's an efficiency advantage in placing Tagged: headers after the
Received: lines in such a timestamping scheme. 

The algorithm for authenticating Tagged: lines would be single pass:

Read each header line. If it's a Received: line, put the timestamp on
a stack and discard the line. If it's a Tagged: line, check it's
timestamp and see if it exists on the stack. If so, the Tagged: line
is authentic and can be used immediately.

If however the Tagged: headers were above the Received: line, then you
would have to save the full Tagged: line, wait until you read all the
relevant Received: lines below it, and authenticate at the appropriate
line. 

I'll see if I can write up properly those tag spoofing scenarios I described
and add them to the wiki (hopefully in the next few days ;-). 

-- 
Laird Breyer.