[ietf-dkim] SSP security relies upon the visual domain appearance

[Stephen Farrell]

Doug - quick and simple question: does all of this depend
on there being >1 From address?

Douglas Otis wrote:
> DKIM should serve as an excellent mechanism for verifying the domain  
> accountable for the MTA to MTA exchange at the transport level.   
> However, once the email-address is bound in some manner to the  
> transport, a set of significant problems arise.
> 
> In the current SSP draft:
> 2.9  Verifier Acceptable Third Party Signature
> ...
> ,----
> | A Verifier SHOULD accept signatures that correspond with
> | addresses in the "Sender" header, MAY accept signatures
> | that are for identities that the Verifier is certain will
> | be displayed to end users, and MAY accept signatures that
> | pass other tests such as accreditation or reputation.
> | Verifiers SHOULD NOT accept signatures from identities
> | that have no known relationship with the message other
> | than their appearance in the "DKIM-Signature" header.
> '----
> 
>  From this, at least the Sender header must correspond with the  
> signing-domain or the message MAY NOT be accepted.  To meet the  general 
> requirement for a first-party signer, the first From email- address is 
> expected to match the signing-domain where multiple email- addresses may 
> then be required, such as:
> 
> From: <my-account at my-isp.com>, Mustang Sally <Sally at some-school.edu>
> 
> Introducing similar visual confusion for list-servers the following  
> will appear:
> 
> From: IETF-DKIM No-Reply <ietf-dkim-bounces at mipassoc.org>, Douglas  Otis 
> <dotis at mail-abuse.org>
> 
> 
> DKIM deployment will prove disruptive when introducing a requisite  
> correlation between an email-address and the signing-domain.  Some  may 
> consider these issues as simple changes in current practices.
> 
> Spending months sorting millions of various spoofs, I still find  myself 
> missing subtle changes that take a minute even when I know it  is 
> wrong.  Some companies have spent large sums attempting to acquire  
> look-alike domains.  There is also an emergence of more than one  
> million characters where many overlap ASCII, and where perhaps even  
> puny-code compatible TLDs are not far off, rather than using multiple  
> character-sets within a domain name.
> 
> See:
> http://www.circleid.com/posts/in_pursuit_of_idn_perfection/
> 
> A quote out of context from a comment to this article by Suresh:
> ,---
> | I would have thought that people over the ages will have
> | become extremely wary of ad-hoc fixes and technologies
> | that don't have global consensus, and which fail non-gracefully
> | in the case of edge situations.  But no :(
> '___
> 
> The initial response to puny-code in some applications has been to  
> turn-off the display of the referenced fonts.  Will displaying the  
> puny-code for the segment of the population relying upon this  
> technology prove helpful for detecting a spoof?
> 
>   For example: xn--cjsp26b3obxw7f.com
> 
> Puny-code places visual examination of the domain for security  purposes 
> well beyond reason.  Even when restricted to just ASCII,  spammers have 
> proven resourceful at finding visually similar urls  where perhaps a 
> 1/l/I are interchanged or an extra l is added.  Of  course, the majority 
> of email readers only see the pretty-name not  checked against SSP 
> policies.
> 
> It would be reasonable for the MUA, and in some cases the MTA, to  track 
> the signing-domain with that of the email-address.  When these  two 
> items change their relationship, the recipient can be alerted to  
> perhaps even the most subtle of change.  This would ensure recipients  
> detect spoofs as those of a prior correspondence.  This approach  would 
> not require the email-address correspond in any manner to that  of the 
> signing-domain, or require an out-of-band policy mechanism.   Better 
> still, this would not disrupt current practices allowing for  the normal 
> use of the From header and for list-servers to sign their  mail without 
> extensive changes to list-server applications and the  corresponding 
> handling by the MUA.
> 
> -Doug
> 
> 
> 
>  
>    _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
> 
>