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" <[EMAIL PROTECTED]>
To: "IETF-DKIM" <[email protected]>
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: <[EMAIL PROTECTED]>, Mustang Sally <[EMAIL PROTECTED]>
>
> Introducing similar visual confusion for list-servers the following
> will appear:
>
> From: IETF-DKIM No-Reply <[EMAIL PROTECTED]>, Douglas
> Otis <[EMAIL PROTECTED]>
>
>
> 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
