Re: [ietf-dkim] SSP acceptance chart

On Nov 2, 2005, at 4:14 PM, Hector Santos wrote:
> > This is indeed a common refrain.  Until MUAs are modified, DKIM
> > offers no such protection however.
> You are limiting your scope to offline world. What about the online  
> world?
The majority of users see only the pretty-name and are enticed by the  
HTML content of the message itself.  Depending upon a From matching  
some signing-domain will not offer much protection, as abusers will  
provide an endless stream of messages meeting these requirements.  As  
counter-intuitive as this may seem, assurances offered by SSP of a  
domain matching are risky, and authorizations only expose the email- 
domain owner to added risks when unfairly held accountable.  SSP  
actually hurts more than it helps.  SSP also takes away an ability to  
send messages to list-servers or to use email-addresses at different  
providers by making it impractical to allow independent signing-domains.
> > When MUAs are modified, the signing-domain should be made
> > visible in some manner.
> Why?
>
> In the perfect world of "chain of trust", the users just wants to see:
>
>     FROM:
>     TO:
>     DATE:
>     SUBJECT:
If you want to authenticate the author independently from that of the  
transport, then the OpenPGP model would be a far better choice.  This  
would return control to the domain owner where there would not be  
risks associated with authorization schemes and possible provider  
negligence.
If the domain offering the transport is to be held accountable by  
DKIM, then there is a "connecting piece" missing when the signing- 
domain and the email-address are not the same.  Even Mark suggested  
there is a desire to allow the signing-domains and email-address  
domains to differ at times.  Making allowances for these two domains  
to be different is needed when not disrupting existing email services  
and practices.  Perhaps people wish to use their alma mater domain  
from their local provider.  Perhaps people want to be able to  
understand who is speaking on a list-server. The connecting piece  
could be an opaque-identifier that extends the chain of trust  
uniquely from the author, over the transport, to the recipient.  Of  
course, the opaque-identifier would not be needed in those cases  
where the domains are not different, and the email-address is limited  
to the author.
> > This could by  done when an initial message is received, where
> > the user is asked to approve these identifiers.
> Why can't his ISP do it for him?
In some cases, this would be possible.  If the signature indicated  
that the email-address domain must always match the signing-domain,  
and that the email-address (for a class of keys) always applies  
uniquely to the author, then this could be could be done  
automatically by the MDA or MUA by initially capturing this assertion  
from an initial message.  When the email-address and the signing- 
domain differ, it would be better to let the recipient decide on a  
case-by-case basis.  This would not require endless requests of the  
provider to create hopelessly complex "third-party" authorizations  
where there would be endless lookups groping for all the possible  
relationships. Double yuck.
> > Anytime an identifier appears to have changed, or another
> > message looks like a message with retained identifiers,
> > they should be alerted.
> Why bother and confuse the user at all?
People change providers, but wish to retain use of an email-address.   
This is a normal process.  People could be alerted to these changes  
ahead of time, so that when the change appears, it is readily  
accepted.  I use SSH, where it is common for me to accept the  
certificate details of the server.  Sometimes these certificates  
change and I am alerted to this change, and once again asked to  
review the details.  Other than that, there would not be much  
bother.  Establishing a database of prior correspondent identifiers,  
that may include pretty-names for example, would allow a program a  
simple basis of when to alert the user to a clever spoof attempt.
> > In that case, there would no need for an SSP scheme.
> > None!
> I love your ethusiam.  But its not doing it for me. Sorry.
You represent the typical provider.


> > This could be enhanced by offering recommendations
> > contained directly within the signature on the scope
> > of identifier needed to isolate the author.
> Is this at the 821 level?
This would be at the 2822 level and affected by the class of key.  If  
there were binding assertions made or captured that were in conflict,  
the identifiers would likely be a combination of <email- 
domain>:<signing-domain>, or <email-address>:<signing-domain>, or  
<email-address>:<O-ID>:<signing-domain>.  This enhanced MUA should be  
able to highlight possible conflicts, were the related bindings could  
be exposed by a click.
-Doug

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