[ietf-dkim] Re: Attempted summary

[Douglas Otis]

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