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

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Apr 2006 15:32:29 -0700

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

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.

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

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
(2) expired signatures are definitely invalid.  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?

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.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Apr 2006 15:59:19 -0700

>This causes me to ask, what good is a best-before date on a signature?

Good question. I don't agree with the people who want it to mean 
"don't check for the signing key after this date". That's silly: it's 
a simple DNS query, it takes less effort to reject than it does to 
start a TCP connection.

>So what should we do with it then?

More good questions. "I, the sender, want this to not be able to be 
validated after this date" is all well and good, but the sender's 
wishes go directly against the recipient's wishes, which are to have 
as many validated messages as possible.

The logic gets even more tortured when you spell out the whole 
equation, which is "I, the sender, want this to not be able to be 
validated after this date, but if you have already validated it, oh 
well."

>sure what to do with the x= value in the first place.

Some folks wanted to tell the receiver what time reference to compare 
to for "best before" or "expiration". If there is an indication that 
users want to listen to the sender about validation, they may want to 
know this detail.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Apr 2006 17:04:05 -0700

> as many validated messages as possible.

That's not correct. The receiver's motivation is to defend itself. 
Validating messages
a priori does not do that. If a sender through its own policy says 
"don't trust/honor/blame me
this after this time", why should a receiver not honor that? That 
information only negatively
reflects on the message,  so a receiver should be happy to know.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Apr 2006 17:09:56 -0700

At 5:04 PM -0700 4/24/06, Michael Thomas wrote:
>>wishes go directly against the recipient's wishes, which are to 
>>have as many validated messages as possible.
>

Correct.

>Validating messages
>a priori does not do that.

True, but does it hurt to do so? If a recipient validates a message 
that has "expired", what is the harm to the recipient? The advatage, 
of course, is that they are now sure where the message came from; 
this is the same as in the normal, unexpired case.

>If a sender through its own policy says "don't trust/honor/blame me
>this after this time", why should a receiver not honor that?

If that policy makes no sense for the recipient (the sender was 
responsible at time X but not at time X+1), then the recipient would 
still want to know whether the message came from the putative source.

>  That information only negatively

Some recipients might be, others might not care.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Apr 2006 17:18:45 -0700

On Apr 24, 2006, at 3:32 PM, Jim Fenton wrote:

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

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

> 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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Apr 2006 17:42:35 -0700

Paul Hoffman wrote:

> of course, is that they are now sure where the message came from; this 
> is the same as in the normal, unexpired case.

All I'm trying to point out here is that the sender and receiver's 
motivations are
not at odds with each other. In fact, they seem quite aligned to me. And 
that's
true even if the receiver goes ahead and does the key lookup anyway; in both
cases, it has pretty reliable information from the sender that 
something's not
kosher, and that's always useful for receivers.

> still want to know whether the message came from the putative source.

I don't see why it doesn't make sense, but if the only thing that we're 
differing
on is whether a receiver may or may not do the validation after the 
expiration
time... I don't really have much feeling one way or the other about 
that. I tend
to think they shouldn't, but I could live with it being a choice for the 
receiver
and defer this argument until we actually have some wide deployment 
experience.

       Mike

---

From: Jon Callas <[email-masked]>
Date: Tue, 25 Apr 2006 14:07:56 -0700

On 24 Apr 2006, at 5:09 PM, Paul Hoffman wrote:

> that has "expired", what is the harm to the recipient? The  
> advatage, of course, is that they are now sure where the message  
> came from; this is the same as in the normal, unexpired case.

There's nothing wrong with it, I don't think. It's just that they way  
the present text reads to me, if I am to follow the signer's wishes,  
it is to reject a priori. If we want different, we should just say so.

	Jon