Re: [ietf-dkim] Not exactly not a threat analysis

On Aug 23, 2005, at 8:47 AM, Keith Moore wrote:

> > Concluding there is significance for a mailbox address assumes  
> > mailbox-
> > addresses are normally constrained by the signing domains, or that  
> > DKIM
> > establishes an appendage of mailbox-address authorizations.  It also
> > seems you want this to include some type of path registrations to
> > regulate forwarding and mailing lists as well.
> I don't know where you get that idea.  I've talked about having  
> separate kinds of signatures for authoring vs. transmission.   
> That's a long way from any kind of "path registration" or  
> regulation of forwarding or mailing lists.

Domains will not likely transform underlying authentication  
infrastructure to implement DKIM.
However, go back to the MUA concept that captures message bindings.   
This technique does not expect a sending domain restrict mailbox- 
address use or DKIM to publish detailed authorizations for mailbox- 
addresses and related signing domains.  Rather, the MUA binding  
technique could associate the mailbox-address, the signing domain,  
and opaque-identifier based upon a trusted initial message.  Even  
when there is no mailbox-address constraint made by the signing  
domain, this binding could still resolve to individuals, provided the  
opaque-identifier was related in some fashion to the method of access.
I see advantages related to how the opaque-identifier (revocation- 
identifier) could be used with respect to MUA implemented bindings.   
The signing domain could also indicate only the mailbox-address  
domain and the domain signature should be included within the MUA  
bindings.  This may be a good choice when the domain does constrain  
the mailbox addresses.   This would minimize the number of such  
bindings needed to safely communicate with such a mailbox-domain.
Once mailbox-address authorization/protection is considered to be a  
function of the MUA, the MUA can be expected to notice a bound  
mailbox-address is having the pretty name mimicked, or a look-alike  
name is being used, or that a different signer or opaque identifier  
has been found within a message.   While this would be a rather  
simple process for an MUA which would be taking advantage of a simple  
mailbox-independent DKIM signature, it would be a nightmare to  
implement these specific mailbox-address authorizations a priori, and  
within DNS no less.

> > I would rather ALWAYS hold the signing domain accountable for any  
> > type
> > of abuse.
> If you put signing domains in the position of accepting  
> responsibility for any type of abuse, you do several things.  One  
> is that you make it more difficult for domains to justify signing  
> messages.  And because "abuse" is subjective (one recipient's spam  
> is another recipient's useful ad), you end up both legitimizing  
> some amount of abuse and marginalizing useful and valid behavior.

Here I do not agree.  There must be a hierarchy of accountability.   
While abuse may be considered subjective, much of the abuse will  
still be avoided by excluding domains that do not respond to abuse  
reports, or that do not take advantage of abuse feedback options.   
Because DKIM permits a rather simple method of constructing name  
based white-listing, it would seem foolish not to provide every  
indication your domain establishes good governance and eliminates  
problems as discovered.  The opaque-identifier should also make such  
an effort of isolating abuse both fast and effective.  A mailbox- 
address would never be as useful.  The opaque-identifier approach  
should also be an attractive feature, once MUAs are implemented to  
utilize DKIM information.  The alternative pushes accountability down  
to each individual mailbox-address and means this exercise of  
confronting abuse be repeated by every recipient.

> I think authors of a message should be able to sign the fact that  
> they authored the message, so that they can prove to their  
> recipients that such messages are not forgeries.

This is where protocols like S/MIME retain their relevance.


> As for the revocation identifier, I think it's an interesting idea  
> - though I still think it's quite reasonable for DKIM to support  
> signatures from individual addresses, and I don't think one should  
> preclude the other.

Does DKIM preclude the use of S/MIME or OpenPGP?  With the MUA  
binding technique, it could work in the same fashion as often used  
for self-signed certificates with SSH.  Click a button that says  
"secure identity" of this message.  The prompt then shows the  
complete pretty name, mailbox-address, the signing domain, and the  
opaque-identifier with the question, Retain this ID binding?  Any  
subsequent prompt for this same address could ask whether to exclude,  
merge, or replace a prior binding.
-Doug




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