Re: [ietf-dkim] "Best Before" vs. "expiration" date
2006-04-24 17:32:02
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|