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

I'll be really interested in which POLICY causes this low likelihood, low
impact problem?

-- Hector


----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
Cc: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, November 17, 2005 5:27 PM
Subject: Re: [ietf-dkim] SSP security relies upon the visual domain
appearance


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(_dot_)com>, Mustang Sally 
<Sally(_at_)some-school(_dot_)edu>

Introducing similar visual confusion for list-servers the following
will appear:

From: IETF-DKIM No-Reply <ietf-dkim-bounces(_at_)mipassoc(_dot_)org>, 
Douglas  Otis
<dotis(_at_)mail-abuse(_dot_)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


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



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