Doug Otis wrote:
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP
client as a weakly "authenticated origin identifier". The IP
address of the SMTP client is the input for Sender-ID or SPF
*authorization* mechanisms.
Hm... the IP address is authenticated by the TCP session.
Yes, weakly authenticated.
Next, the self-styled domain is looked up checking for an
authorization for the given IP address.
Such as example.com references an SPF record that produce the following:
Received: by SMTP id j2cs23447wfe;
Tue, 24 Feb 2009 09:51:01 -0800 (PST)
Return-Path: <info@xxxxxxxxxxx>
Authentication-Results: trusted-isp.com; spf=pass smtp.mail=example.com
...
--- or ---
Received: by SMTP id j2cs23447wfe;
Tue, 24 Feb 2009 09:51:01 -0800 (PST)
Return-Path: <info@xxxxxxxxxxx> (SMTP Mail From parameter)
Authentication-Results: trusted-isp.com; senderid=pass
header.from=example.com
...
From: The Club<the_club@xxxxxxxxxxx>
Up to DNS reliability, a positive result proves the validity of the
domain name, in the sense that the domain admins have stated that
messages originating from the given IP may righteously claim to
originate from that domain.
Positive authorization results will not safely indicate whether a
domain originated a message (and will not represent authentication)
when any of the following might be true:
1) Publishing the SPF record was intended to ensure delivery or to
minimize backscatter, but was not to ensure source authenticity.
(Ensuring delivery is a common reason for publishing SPF records.)
2) The authorization reference (such as Mail From or From as above)
was not restricted to just the domain's users. (It is a common
practice not to impose restrictions on the use of the Mail From or the
PRA.)
3) Separate SMTP clients share the same IP addresses. (Unfortunately
this is also a common practice. Brazil, Poland, and other places have
many ISPs that expect hundreds or thousands of customers to run
outbound SMTP services that NAT to a single or small number of IP
addresses. It is also common for VPS services to run servers out of
common IP addresses.)
4) Authorization results that are based upon a virtual record when no
SPF record is found. (Injecting SPF mx/24 record mechanisms whenever
no SPF is discovered is also a common practice.)
5) The SPF Authorization is not intended to be referenced from a PRA
message element. (There may be uncertainty whether a PRA is a valid
reference due to conflicts between RFC 4406 and RFC 4408.)
6) A domain that employs outside email providers to handle inbound
email, but then inadvertently includes an MX mechanism where the
inbound provider also offers outbound services to thousands of domains
from the same IP address space. (This now will likely be found to be
a common mistake.)
Why wouldn't that make up an authentication of the given domain name?
Any common situation from 1 - 6 eliminates any reasonable assurance
that a domain originated the message. It can only be said that a
domain *authorized* the SMTP client. Assigning reputations to a
domain on that basis is not easily reconciled, nor will marking the
domain "unsuitable for annotation" offer timely protection for other
domains that are also sharing the SMTP client IP address. This is not
about blocking messages, this is about annotating messages.
Checking the reputation of the "authenticated origin identifier"
determines whether this identifier protects the message elements
used to establish the *authorization* prior to revealing the
*authorization* results.
It is not clear to me what checking would the MUA do in practice.
When annotating a domain as having originated a message is based upon
SMTP client authorization, the reputation of SMTP clients is
critically important. As enumerated by the list 1 - 6, not all IP
addresses used by SMTP clients will restrict a domain's use to just
their users.
[...]
In addition, including the IP address of the SMTP client makes the
header less deceptive. Recipients must consider which identifier
has been authenticated. It is the *authenticated* IP address of
the SMTP client that is being *authorized* by Sender-ID or SPF.
Using this IP address to replace the local-part avoids the
conditional inclusion of the local-part that is required by section
2.4.3.
I doubt that displaying "192.0.2.3@xxxxxxxxxxx" will make the
recipient safer.
The alternative might be "HR@xxxxxxxxxxx" is used with a message
asking you to complete your W2 form at a specific web-site.
Unfortunately, the MUA is unable to check whether 192.0.2.3 has a
recent history of spoofing domains. Employees of example.com may be
unaware of the limitations imposed by their outsourced email service,
or may have created records intended to help ensure message delivery.
Bad actors can now leverage any "righteous" assumptions that border
MTAs might make to produce extremely convincing socially engineered
attacks. See items 1- 6. These attacks are made easier whenever
*authorization* is erroneously elevated into being considered
*authentication* without adequate safeguards being provided.
Safeguards based only upon a domain will not isolate the services
culpable for domain spoofing and will inhibit an effective response to
SMTP client exploits.
Users who know what to do with an IP address are also able to look
at the Received or Received-SPF headers directly. MUAs tend to
conceal even true email addresses from end users, for some reason.
When Authentication-Results headers cause a consolidation of added
headers, SMTP client IP address may no longer be available when
processing *authorization* mechanisms. The Authentication-Results
header can occur at subsequent MTAs which does not help identify which
Received header can be trusted. In addition, not all Received headers
include the IP address of the SMTP client. Inclusion of the SMTP
client IP address is being sought is to better determine whether it
might be safe to reveal authorization results.
This section confuses authorization with authentication where even
local-part authorization can only be determined after examining
internal elements within SPF records. Tracking the *authorization*
role of the local-part is not a defined output of either
authorization mechanism, nor is it safe to process SPF record local-
part macros!
A domain interested in verifying the local part might combine the
"exist" mechanism with a purposely built DNS zone.
The SPF exist() function must combine local-parts with the IP
addresses of the SMTP clients. Using the macro "exists:%{ir}.%{l
+_}._spf.%{d}" will authorize a message that references an A record at
"_spf.<domain>" with labels that comprise reverse octets of the SMTP
client IP address followed by local-part characters, where '+' and '_'
characters are replaced by periods. While the macro capability of SPF
offers flexibility, it also provides bad actors the ability to define
any new sequence of 10 DNS transactions constructed from a single
cached SPF record.
What's wrong with processing local macros?
During a spam campaign, by varying local-parts (which is already
normally done), any macro driven transactions may just expend the
recipient's DNS resources, and target any otherwise innocent domain.
This provides an otherwise free method to attack while spamming. Any
method to combine the user namespace with SMTP client authorization is
likely to require a substantial amount of recipient generated DNS
traffic.
I agree that if no local macro has been processed one can safely
consider the local part as not having been validated. However, the
converse statement does not hold.
A) It might be painful for innocent third-parties when recipients
process local-part macros.
B) There is no output specified by the SPF mechanism to indicate what
portion of a local-part, if any, plays a role in the authorization.
I'd say that only MTAs whose SPF-checking implementation traces the
use of local macros may conclude that the local part was not
specifically checked, and thence conceal it.
In converse, conditional annotations based upon the use of local-part
macros will encourage the use of this dangerous mechanism.
Another not commonly implemented possibility is that a site
dynamically updates its DNS records according to DHCP leases, and
synchronizes the SPF record TTL with the lease duration.
Agreed. This is not common.
How would a MUA cope with that if, say, it downloads the message on
the next day?
If such dynamic use of SPF were to become popular, a reputation
service could return A records where the least significant bits encode
the number of second since a problem was noted. It seems unlikely
there will be a demand for solving this issue, but it would not be
impossible. Our service already tracks hundreds of millions of IP
addresses where activity is already measured in this manner.
It is fairly common to accrue reputations over a range IP addresses.
When this range of IP addresses does not spoof domains, revealing
results should be safe. It is also fairly common for ISPs to
transparently intercept port 25 traffic or to force the sharing of
common IP addresses. In this case, it is _never_ safe to assume that
an authorized SMTP client provides even a modicum of proof that a
particular domain originated the message.
Only the IP address of the SMTP client offers a practical means to
track IP address sharing. Attempting to track IP address sharing by
domain will be fairly impractical since tens of thousands of domains
might authorize the same IP addresses, but SPF does not offer a
reverse namespace. Marking a domain as "unsuitable for annotation"
that never issued abuse is likely to incur expensive support calls and
involve the SMTP client providers anyway. Not including the SMTP IP
address will produce more victims for confidence artists and make
defending an authorization mechanism more expensive.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf