ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Attempted summary

2006-01-26 14:52:36

On Jan 26, 2006, at 12:22 PM, Mark Delany wrote:

Great. Will this also work with other (i.e. non-list) forms of forwarding?

I can't see why not particularly if:

the mere presence of a signature does not imply anything more than taking responsibility for what emanates from that domain.

If Mike is saying that explicitness is necessary, then I think that gels with Wietse.

I'm sorry Mark, this is a bit too terse for my semantic analyzer.

I take that as a complement on this list ...

-base
just says "this is what I claim passed through me". -ssp requires a binding between the From: address (sender:? listId:?) and the i= to validate the policy binding, if any.

Maybe it's just that I'm confused about what's being asked here.

Right. So the question is, can a signature be constructed such that it doesn't interact with SSP to infer a binding above and beyond "I claim it passed through me"?

This idea has been explored in the dkim-options draft, although perhaps not well explained. This draft includes a 'w' parameter within the signature. Perhaps this could be described as the "What role or verification semaphore."

http://www.ietf.org/internet-drafts/draft-otis-dkim-options-00.txt

The signature should allow expressions beyond "it passed through me". The signature could indicate the purported role of the signer, such as a signature on behalf of the MSA, MUA, mediator, or MDA. The MSA/MUA could be differentiated by an indication via the key that the signature is less trustworthy, which reduces the list to just MSA, mediator, or MDA. Use of the MDA role for the signature would be to ensure messages are not tampered with while en-route within the receiving AdmD, especially with a practice that overlays the signature with results. The overlay could be a means to prevent anyone within the receiving domain staging abusive replay attacks against those sending messages to the domain, or the domain itself, as the MDA signature would never be accepted elsewhere.

The signature should also be able to indicate what had been verified within the message. Currently, the 'i=' parameter provides a means to express a validation of some email-addresses only within the signing domain. If an opaque-identifier were used and verified, there should also be a standardize way of expressing that this non- email-address identifier has been verified, which can help resolve email sources within a domain in a manner independent of an email- address.

Imagine a large provider signs any and all messages. Injecting a Sender header alters the appearance of the email. An essential goal of DKIM is to not alter the appearance. Sender header may also be in conflict when this header is already included within the message being sent. To allow the identification of unique sources with the domain, the provider may instead include an account identifier within the signature. The account identifier can be obtained from the authentication at the MSA when accepting the message.

This account identifier is constructed in a manner to allow a "redemption" table to be prefixed above the account identifier (O- ID). This prefixed table value allows the revocation of messages from a specific account, while allowing an easy means to re-enable new messages from the account. This would not depend upon the use of an email-address, which creates additional exposure to email abuse, or a greater loss of privacy.

The same 'w' semaphore mechanism can replace the 'i=' parameter by associating a header with a signing role. The MSA would always be associated with the From, but never would the mediator. Perhaps the mediator would always associate with the Resent-* header. Specific codes could be created for specific headers. The signing semaphore can indicate more than just roles, but also verification assurances. These assurances may be the entire email-address is always verified (w=d), just the domain of the email-address is always verified (w=a), or that any email-address for this domain is always signed and verified (w=b), or that this email-address is always signed and verified (w=n).

If there is a policy either obtained or cached for a specific email- address, it should differentiate between the source of the message based upon the role of the signature. The current concept of the SSP precludes making this differentiation, but a next generation of MUA should have no difficulty being able to treat role identities separately without degrading safety. Perhaps there could be signaling semaphores that indicate a mediator is not allowed for a scope of email addresses, as an interim solution. This was not explored in the dkim-option draft.

-Doug



_______________________________________________
ietf-dkim mailing list
http://dkim.org