[ietf-dkim] SSP security relies upon the visual domain appearance
stephen.farrell at cs.tcd.ie
Thu Nov 17 14:27:16 PST 2005
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.
> 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
> 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.
> ietf-dkim mailing list
More information about the ietf-dkim