[ietf-dkim] "Best Before" vs. "expiration" date
dotis at mail-abuse.org
Mon Apr 24 17:18:45 PDT 2006
On Apr 24, 2006, at 3:32 PM, Jim Fenton wrote:
> I believe I took an action on Thursday's Jabber session to state more
> clearly my concerns about x= semantics.
> Stephen's proposed text used both the terms "expiration" and "best
> before" to describe the x= value. These are very different
> concepts. An expiration on a signature would mean that the
> signature is no longer valid after that date/time.
No longer valid by date-time implies this parameter is assessed when
the message is initially received. It does not make sense to accept
a message, then at some later date, downgrade the message on its way
to the recipient. How does an accepted message go from being good
one second, and invalid a few seconds later?
The recipient is able to judge a normal range of latencies for
received messages. The expiry parameter represents an attempt by the
sender to influence this judgement. When should a recipient relegate
their judgement of message latencies to that of some sender? The
safe answer is never.
Why? Having this parameter alter the validity of the message is
perilous when considering how sender policies might be applied.
> It does not necessarily mean that the responsibility that led to
> the signature has also expired. The expiration of a signature
> doesn't affect anything other than that particular signature; other
> signatures may exist with different expirations, and regardless the
> message itself isn't expiring.
What value is there expiring the signature when the signer remains
accountable for the message? Should expired messages be free of
> A "best before" date on a signature means that the signature may or
> may not not be valid after a certain date, but don't be surprised
> if you can't verify it any more. There is nothing wrong with using
> the signature after its "best before" date, just like the carton of
> yogurt with a "best before" date of April 8 that I ate yesterday,
> which tasted fine.
Either the message received date-time indicates a "fresh" message
from the perspective of the recipient, and the signature can be
verified, or the recipient can judge the message accordingly.
When the signature has been revoked (p= blanked), this is different
than when the signature can not be found. A revoked signature would
more likely cause message rejection, which is worse than no key, and
perhaps worse than no signature. DKIM can not really dictate this
> In the Jabber chat, Barry thought we had accepted the "best before"
> The primary value in the "best before" date is that it helps
> explain some signature verification failures.
Then the semantics related to the signature being valid or not should
be removed. Adding a parameter in the key indicating the sender's
expected number of days for SMTP latency, or perhaps separately for
MUA latency from either the t= or the message Date field would be
safer and impose less overhead.
> If you get a message that doesn't verify, and it's past the "best
> before" date, then it helps explain the failure. Do you really
> know that this is the reason for the failure? No; in fact, if you
> were able to retrieve the public key and they abide by the
> suggested practice of never changing the key under a selector other
> than to revoke it, it's fairly certain that this wasn't the reason
> for the failure.
A best-before date could be used to game rather complex message
states. Not trusting the sender is a good reason to ignore this
> Furthermore, an attacker could send a message with a signature
> showing a best-before date in the past, and a selector that doesn't
> exist, and there would be no way to know if the signature had been
> valid, or was a complete fabrication. For this reason, you can't
> treat signatures past their best-before date any more favorably
> than any other breakage.
Agreed. Best-before is worthless, but so is expiry. The recipient
should trust their own judgments and not depend upon that of the
sender. The recipient should know their own network far better than
> This causes me to ask, what good is a best-before date on a signature?
> The same thing holds true, with minor changes, under the expiration-
> date paradigm. The only differences are that
> (1) expiration makes it possible to optimize-out the checking of
> expired signatures, and that
This optimization risks being burnt by receiving a stream of messages
with a short time to expiry that might catch down stream. Hardly a
> (2) expired signatures are definitely invalid.
Except the signer is still accountable?
> This leads me to wonder that the value of deliberately invalidating
> a signature on expiration is: about the only use I can think of
> for (2) is to limit the scope of replay attacks, but no, the
> informative text says we shouldn't do that. So what should we do
> with it then?
The recipient would still be a better judge on when a signature looks
too stale. Why trust the sender?
> I'm neutral on the received vs. verification time issue because I'm
> not sure what to do with the x= value in the first place.
This dangerous and problematic expiry parameter should be removed.
It does not add any value to the recipient. It only provides a means
for the sender to game the receiver.
That said, the received time versus verification time preserves the
validity of the message once accepted prior to expiry. What possible
advantage is there expiring a message once it has been received prior
to expiry? Using the current time at subsequent verifications points
does not help with the abusive message replay issue, where short
latencies are likely to be attempted.
More information about the ietf-dkim