Re: feature request: caching message arrival time

["Örjan Ekeberg" <ekeberg@kth.se>]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> Sure, assuming that you trust the closest MTA in the chain of MTAs that
> handed the message off to you, since an adversarial proximal MTA could
> manipulate all the existing Received: headers as well.
>
> But I'm a bit uncomfortable with it: this sort of protection actually
> opens up a new attack vector that didn't exist before -- any MTA in the
> chain can now make the message seem like it was actually from the
> *past*, just by setting its own Received: header.

As far as I understand the autocrypt protocol (i.e. not much;-) ), the
vulnerability is that an incoming message with a later time-stamp than
the locally saved autocrypt status can update the stored state
(e.g. turn off encryption).  Manipulating the time-stamp to make the
message appear to be *older* than it really is should only mean that it is
less likely to update the saved state?

If this is correct, using the oldest of all the time-stamps seen in the
Date-header and any of the Received-headers should be the most
defensive.

/Örjan