ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: get rid of x=

2006-04-12 11:19:44

On Apr 11, 2006, at 9:12 PM, Dave Crocker wrote:

It should talk about being able to conduct a validation within a window of time, and not being able to do it after the window closes. And treating the message as having no signature, absent the ability to do a validation and absent any other validation information (like an authentication header.)

This is not about a "contract signature" becoming invalid. It is more like a traffic light changing. Transit is ephemeral, so it should not be surprising that a mechanism related to transit is ephemeral.

Should the transit time also cover the message being read and verified by the MUA, and not just the MTA?

The transit should include a reasonable time for the message to reviewed by the recipient. This view is consistent with the Threat document that considers IMAP and POP part of the transport.

Adding just a simple header that the MDA considered the message valid at one point raises questions who added the header and removes the protection to be obtained by DKIM. Until all MDAs strip such results, these headers offer a method to dupe recipients and seriously reduces protections being sought with DKIM.

If the desire is to have signatures remain valid only up to the MDA, then the MDA should replace these signatures with theirs, listing the domains that verified. Define a tag in the signature that indicates MDA ownership. This MDA tag should permit long lived signatures, as then these MDA signatures could not be used to send messages elsewhere. This strategy would thwart abusive replay of a message when the signature is replaced. After all, defending against abusive replay is the _only_ justifiable reason for including the x= tag.

Rejecting messages on the basis of expiry raises DSN concerns, as many MTAs are known to be up stream of other MTAs. Avoiding DSNs would then result in an ever escalating 'minimum time remaining before expiration' requirement. This strategy will eventually force abandonment of the use of expiry or perhaps refusal to accept messages signed with the x= tag. It would be impossible to trust all down-stream MTAs will not reject messages based upon the amount of time remaining before expiration.

-Doug

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