ietf-dkim
[Top] [All Lists]

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

2005-11-17 14:25:59
Doug,

It will be helpful to be distinctive and to distinguish which policies in
DKIM/SSP you are concern about:

         NONE (no policy declared)
    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

Obviously your concerns do not apply in general to all policies described by
SSP in the specs or proposed to be added.

So it would be extremely helpful if you can describe the threats and impact
per SSP in itemized format, without injecting a grandiose thesis alternative
solution and preferably in the format described by Jim Fenton and Stephen
Farrell.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Thursday, November 17, 2005 3:54 PM
Subject: [ietf-dkim] SSP security relies upon the visual domain appearance


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

<Prev in Thread] Current Thread [Next in Thread>