On Apr 10, 2006, at 11:38 AM, Jim Fenton wrote:
John Levine wrote:
Parsing and dealing with the value in x= is probably easier code
than doing the same with a date-stamp from a Received header.
I think we all agree that t= is useful to have an easily parsed
version of the time the message was signed.
I have a lot more trouble understanding why t= needs to be kept
than why x= needs to be kept.
An expiry would be easier to exploit when attempting to induce down-
stream bounces. In the case of a bounce, the signature would be
expected to be invalid, the source could be reputable, although the
message may contain abuse now less easily blocked.
The t= is an optional signature parameter, where the Date header
field is required per RFC2822 (3.6/3.6.1) to indicate when the
message was ready for transport.
As a signer, I would much rather specify an expiration time for the
signature than to specify the time at which it was signed than to
have the verifier add a fudge factor to the signing time and use
that as the expiration.
A bad actor would also prefer to specify an expiration. This expiry
parameter will not provide a safe basis for rejection without a risk
of inducing bounces. The Date header remains a viable alternative.
On this list, I have already heard numbers between 1 and 2 weeks
for the fudge factor, so the signer would really have no idea how
long the signatures are valid.
Message signatures can be verified for as long as the signer keeps
the keys available. As an eventual alternative, a revocation
mechanism assures affected message can be safely deleted which avoids
a bounce exploit or response delays. Revocation, checked when the
message is transmitted from a system not associated with the signer,
does not prolong an opportunity for various exploits, as would a
fixed expiry.
In addition to Arvel's comment about the relative difficulty of
parsing date/time out of Received headers, it's a really bad idea
to do that because they're not signed.
It is not a good idea to reject messages based upon a per-second
expiry setting. Rejection on this basis will be easily exploited.
The current strategy of simply using the Date header per requirements
established by the receiver remains a safer choice. The t= and x=
parameters are already optional. Both t and x can be dropped by
simply depending upon the required Date header.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html