On Aug 29, 2005, at 8:36 AM, Hallam-Baker, Phillip wrote:
Domain authorization mechanisms should not make anti-forgery
claims, despite the misleading charter goal.
I think that the problem here is that you are describing an
implementation rather than a specification.
I agree that the type of analysis you describe is possible, the
anti-spam filtering services already have similar processes in place.
The point of SSP is to simply describe the sender signing policy of
the
domain. This helps the recipient interpret unsigned messages
purporting
to come from the domain with greater accuracy.
You are describing a mechanism and explaining what it may accomplish
in the narrow terms of the mechanism. This unfortunately has nothing
to do with claims made within the charter regarding header
authentication.
Lead-in problem statement:
,---
| Forgery of headers that indicate message origin is a problem for
users of
| Internet mail.
'---
The goal of DKIM.
,---
| The DKIM working group will produce standards-track specifications
that
| permit authentication of message headers during transit, using
public-key
| signatures and based on domain name identifiers.
'---
While one could describe signature verification as authenticating the
signature header, this is not addressing the problem statement. The
headers which could possibly relate to forgery are _not_ being
authenticated. I find these two statements misleading and not
representative of the DKIM mechanism as currently devised.
Not accurately expressing goals makes it difficult to evaluate issues
related to their potential success or the related threats.
For example consider the following policies:
* "The domain anybank.com is regularly targetted by phishing attacks,
all legitimate mail from this domain SHOULD be signed"
This simple statement overlooks details related to how "legitimate
mail from" is defined. Of course understanding the motivation
related to this statement would permit an assessment of the viability
of the goal. Leaving out this critical detail allows problems to be
ignored. Getting even this goal clearly stated would greatly assist
the evaluation process. Claiming the SSP mechanism prevents phishing
would be invalid, for example.
* "The domain example.com is performing a limited trial of DKIM, only
some mail from example.com is signed".
You are describing a mechanism that is unrelated to any goal.
* "The domain example.com signs every mail using RSA-SHA256."
Again a mechanism unrelated to any goal.
Each one of those statements provides information that helps a spam
filter to make the right decision.
You have described a mechanism where whether it achieves some goal
can only be evaluated when that goal is clearly stated. DKIM does
not authenticate headers that may be forged which draws into question
what is being accomplished. Describing this as an anti-phishing
solution would be problematic. It would be better to clarify in
general terms what is being claimed as the goals of these SSP
assertions. These assertions are fully independent of the basic DKIM
mechanism, yet there is no goal directed toward achieving DKIM which
I find remarkable.
Your last two points seem to be attempts to justify a mechanism that
offers no value. As the domain controls the private keys, this would
be a stronger assertion of process which does not benefit from
ancillary reinforcement. A domain that signs some messages again
does not address any particular goal nor offers a solution for some
problem.
At this point we basically have two proposals:
1) Try to solve the problems of spam and phishing to the best extent
that email signatures allow
I would rather see clearly defined goals rather than attractive
phrases that appear to promise everything. Attempts to define the
relationship of providers with mailbox-address will be highly
disruptive and should be avoided. To provide a uniform level of
protection, an opaque identifier should be added by the accountable
domain. This permits indirect methods to abate message replay abuse,
author forgery, and unauthorized access.
General goals:
- Establish an accountable domain.
- Establish accountable domain-specific opaque identifier.
- Establish low-level defensive strategies to protect resources.
- Minimize requisite administration.
- Minimize requisite protocol overhead.
Charter revision:
----
Being unable to verifying the domain providing initial access for the
messages being offered is a problem affecting those accepting
Internet mail. The verification establishes a domain accountable for
subsequent messages with expectations of this domain being able to
abate ongoing abuses. A verified domain signature within the message
also affords identification techniques based upon opaque identifiers
offered by the accountable domain. The signed header with the added
identifier could be ancillary to techniques aimed at thwarting
targeted spoofing of prior correspondents, for example.
The DKIM working group will produce standards-track specifications
that will permit the authentication of the domain providing initial
access for opaquely identified entities sending messages. The
authentication process will utilize a dedicated header containing
public-key signatures and verified with public keys stored in the
accountable domain's DNS hierarchy.
...
2) Limit the scope of the work strictly to the minimum.
I think that the second is a major mistake that would result in the
working group taking longer to deliver just the message package
than it
would take to deliver a full specification.
I have been involved in groups that have had clear goals, but failed
to consider important aspects which then produced a well defined
albatross. I would rather see this effort build a solid foundation
that can stand on is own. I see DKIM as that foundation. This
foundation does not need to address spam or phishing directly. This
foundation simply enables tools which allow more effective and
expedient dispatching of abuse related issues. I have doubts that
SSP practical and would rather see SSP considered separately.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org