Re: [ietf-dkim] Re: Attempted summary

On Jan 26, 2006, at 4:59 PM, Jim Fenton wrote:
> william(at)elan.net wrote:
> > On Thu, 26 Jan 2006, Mark Delany wrote:
> >
> > > 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"?
> > Make 'i' optional.
> 'i' is optional, but takes the value @d if it is missing.
>
> > My preference however is to have field in signature that specifies  
> > what type of email parameter the signature is associated with  
> > (i.e. see 'id' segment of metasignatures).
> If we know this, presumably one could tell, for example, whether a  
> signature came from a mailing list.  But it's the signer's  
> assertion what their role is:  one might imagine setting up a rule,  
> "I'll accept any messages re-signed by mailing lists."  So the Bad  
> Actors will just start adding a few more headers, and all of a  
> sudden you're getting lots of mail from the unbelievable- 
> deals(_at_)example(_dot_)com mailing list, with messages from "people" talking  
> about what great deals they got.
This overlooks an important application of the DKIM signature.  An  
approach using DKIM can ensure look-alike domains, use of unicode,  
ACE labels, or display-name only headers will _never_ be a problem.   
This would be the use the DKIM signature to both register and  
recognize the source of a message.  Simple "out-of-band" methods can  
ensure the source of the message, such as including pass-phrases or  
pictures selected when subscribing to a service.  Once registered,  
these messages can be marked to signify it originates from a  
recognized registered source.
When there is an apparent conflict, the recipient should be warned.   
Their registration may need to have the source of the message  
ignored, merged with or replace the existing registration, or perhaps  
blocked as a spoof.  This conflict notification would be a nuisance  
without the role of the signer also included.  When the Mediator role  
is noted, the next generation MUA would be able to ignore innocuous  
Mediator conflicts with an MSA source, the likely case.
The lack of a registered marking on a message that purports to be  
from a registered source would alert the user as well, hence this  
would be highly spoof resistant.  This approach allows the safe and  
painless use of Mediator related services.  The source of the message  
could also indicate that a Mediator role is not permitted, but this  
was not covered in the dkim-options draft.  It seemed better to  
assume prohibiting the use of Mediator sources will not be required,  
following the introduction of the next generation MUAs, or plug-ins  
and pre-filters for legacy MUAs.  By the way,  signature overlays and  
the MDA role will be needed to accommodate markings made by pre- 
filters to support legacy MUAs. : )

> Since there's no way to know what the role of the signer really is,  
> it's not a useful piece of information.  What is useful is who the  
> signer is, and then the verifier or recipient might recognize it:   
> Oh, it's signed by mipassoc.org, which gives the responsible  
> address as ietf-dkim-bounces(_at_)mipassoc(_dot_)org(_dot_)  I know that's a mailing  
> list.
You don't need to know the true role of the signature.  As with  
virtually everything within a DKIM signed message, beyond the domain  
of the signature, nothing should be trusted.  With that in mind,  
being able to differentiate between an MSA that purports to be that  
of your bank, and those on a financial list-server posted to by  
employees of your bank, allows you to understand these as coming from  
different sources.  This differentiation allows the next generation  
MUA or pre-filters to ignore harmless the role based conflicts.  All  
those important messages will be marked as registered with far less  
interaction.
Phishing protection requires a pre-filter that must _not_ assume that  
the From address is being spoofed.  This is the assumption being made  
with SSP.  That assumption represents a serious flaw in the  
protection being sought.
It seems rather safe to assume that with the aid of just the base  
DKIM signature, intelligent pre-filters and next generation MUAs will  
remove most spoofing concerns.  There will be extremely little  
administration needed, as there is no complex matrix tables returning  
multi-level acceptance results, or email-address domain owners  
wondering where their email went.  Recognizing the source of a  
message provides yes or no results for the recipient.  Remember, the  
majority of recipients only see the display-name.  When erecting a  
barrier, be prepared to handle exploits using a different avenue.   
Currently, main street is bustling with blind users expecting  
protection.  With the SSP approach, they will not see what hit  
them.  : )

-Doug




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