[ietf-dkim] "Best Before" vs. "expiration" date

[Douglas Otis]

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  
accountability?


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


> In the Jabber chat, Barry thought we had accepted the "best before"  
> semantic.
>
> 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  
parameter.


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


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


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

-Doug