On Dec 19, 2008, at 11:58 AM, Victor Duchovni wrote:
On Wed, Dec 17, 2008 at 06:24:16PM -0800, Douglas Otis wrote:
Not listing this information borders on negligence.
Or perhaps repeating this information ad nauseam borders on
fanaticism.
The Authentication *Results* header communicates the *Results* of
various mechanisms that determine the domain which is responsible
for sending a particular message. While we can quibble over whether
these are Authentication or Authorization results (and I might even
agree with you that the latter fits better), this is largely
irrelevant, either way the mechanism attempts to determine the
responsible domain and adds the results to a header, and downstream
filters can use this information to make decisions.
Considering the "authorizing domain" as the "authenticated domain" is
being negligent. It is being negligent since authentication is
necessary when dealing with reputations, and since authorization alone
prevents mitigation of various exploits.
Systems are being compromised in different ways. While knowing that
Domain X intended to authorize SMTP client Y with domains found in the
MAIL FROM or the PRA may reduce erroneous message rejections, the
Authentication-Results header may support annotations that are likely
trusted by end users.
Without including the weakly authenticated IP address of SMTP client
Y, its omission prevents the annotation agent that is dependent upon
the Authentication-Results header a practical means to mitigate likely
exploits through reputation checks of the SMTP client Y, the _actual_
source of the message. These exploits might be due to access breaches
or due to incorrect assumptions regarding intended use of
authorization records.
When one trusts the responsible domain (if one is provided by via
the A-R header) in some fashion (say to not send you spam), one
grants the responsible domain greater access (say bypass CPU
intensive and FP-prone filters). Within this limited security model
it does not matter that a strict notion of "authenticity" cannot be
inferred from the A-R header.
Section 4.1 correctly stipulates the reputation of the _authenticated_
origin of the message be checked. While one may wish to check the
reputation of the authorizing domain, this check is likely of little
value and is of questionable merit. The important reputation check
must be that of the _authenticated_ origin of the message. In the
case of Sender-ID or SPF, the authenticated origin is the IP address
of the SMTP client, and is not the authorizing domain!
If you must have message authenticity, use (with care) S/MIME or PGP.
The authorization provided by either Sender-ID or SPF is based upon
the weakly authenticated IP address of the SMTP client. If the IP
address of the SMTP client were in doubt, authorization of that
address would be meaningless. While, something more stringent like
DKIM, S/MIME or OpenPGP would be better, DKIM was developed was to
ensure the message appearance did not change which might arouse end
user suspicions.
If you want to allow receiving systems to separate determination of
the responsible domain from acting on the reputation of that domain,
standardize a header that records this domain.
Must we change the header name to
This-Is-Not-Authentication-Just-A-Determination-Of-The-Responsible-
Domain:
Even this header would be wrong. :^(
For example, Domain X publishes a version 1 SPF record. RFC 4406
(Sender-ID) considers the version 1 record scope to be PRA and then
MAIL FROM, whereas RFC 4408 considers the scope to be only MAIL FROM.
Domain X employs provider Y to forward outbound email, a typical
scenario. Domain X publishes an SPF version 1 records which include
the IP addresses of provider Y to help with backscatter or to improve
message acceptance, as you described. As it turns out, provider Y
does not evaluate the PRA. Perhaps doing so may cause loss of
intellectual property in the case of a dispute, or require a database
maintenance and additional overhead to associate accounts with PRAs.
Confidence Artist Z has found many receiving domains use M MUAs, that
might apply Sender-ID against version 1 records, especially when there
is an Authentication-Results header that includes Sender-ID results
which fails to indicate the record type found. The authentication-
Results header makes the incoming MTA a patsy for any record scope
errors. Provider Y does not control the nature of the SPF record, so
they can proclaim innocence of any error in the application of record
scopes. Ironically, the warning added by IESG perhaps makes them most
culpable.
Domain X uses email to issue important information regarding component
availability, where their webpage also includes their valued customer
list. Confidence Artist Z only needs to check the SPF record for
Domain X to discover who is their provider. Confidence Artist Z then
obtains an account with provider Y to issue messages able to spoof
Domain X in the PRA. The Sender-ID checks will pass, where MAIL FROM
checks are not required by Sender-ID.
A reputation service that tracks phishing attempts and exploit in
realtime, can safely report SMTP client Y does not restrict access to
the PRA. The reputation service, not wanting to be sued, is careful
not to indicate that Domain X is issuing phishing messages, or that
they are responsible the egregious scope errors being made. To ensure
the correct party is identified and reported upon within a reputation
check, only the _authenticated_ and not the _authorizing_ identifier
must be used.
in order to discourage misuse?
It would I think be more productive to move beyond the header name
(or fixation on authentication vs. authorization in SPF/SID, as the
same observations also apply to Domain Keys and DKIM) and suggest
any necessary improvements to the draft that clarify the security
model.
DKIM provides a means to authenticate the originating domain. The
concern is not about including the SMTP client IP address in the case
of DKIM.
There are however snakes in that pit. The question of whether email
"authentication" (i.e. DKIM, SPF, ...) will/won't/must/mustn't
solve "phishing" remains unresolved with strong views on each side.
If the draft takes sides in this "debate" (cream-pie throwing
contest?), it may never see the light of day.
There should be a debate with those arguing that an authorizing domain
is a replacement for an authenticated origin, the SMTP client IP
address, when checking reputations. While understandably few within
this WG want to see the identity of their outbound servers included
within the SPF or Sender-ID results, that bias should not be
surprising. Unfortunately, its removal prevents a means to properly
handle exploits related to the Authentication-Results header and to be
compliant with Section 4.1.
No one has provided any reasonable justification for excluding the IP
address of the SMTP client within the Authentication-Results header in
the case of Sender-ID or SPF. Deceptive misuse of this
Authentication-Results for Sender-ID will be coercive, injurious, and
lack reasonable mitigation methodology that is not highly disruptive.
There have been rather lame excuses such as there are no I-Ds or RFCs
that determine which IP address should be included. Of course, this
excuse ignores the fact that the _same_ IP address is a parameter that
MUST BE passed to the process evaluating SPF records since its value
might be used in macro expansions, or compared against the CIDR lists
contained within SPF records.
I am reconciled to the fact that some will abuse the header to
colour the MUA chrome to suggest that the user is looking at a
genuine message:
good enough to enter your bank-account password into a web-form
referenced in a link from the message. I hold that this would be a
misguided use of the A-R header, but I don't think I can win this
argument yet. We just need to wait a decade or more and see how A-R
is used with the benefit of hindsight.
There is _no_ reason to exclude the authenticated origin of the
message to better deal with any possible exploits.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html