New email headers' misuse of the term "authentication" will prove
highly deceptive for recipients and damaging for domains!
The Random House dictionary definition of "authenticate" says:
1. to establish as genuine.
2. to establish the authorship or origin of conclusively or
unquestionably, chiefly by the techniques of scholarship: to
authenticate a painting.
3. to make authoritative or valid.
The Oxford dictionary adds:
[ intrans. ] Computing (of a user or process) have one's identity
verified.
When a header is labeled "Authentication-Results" and contains "my-
trusted-isp.com; sender-id=pass jon-doe@xxxxxxxxxxx", a reasonable
person should expect this gives recipients the impression that "my-
trusted-isp.com" has confirmed that the message originated from "jon-doe@xxxxxxxxxxx
."
Available public information for path registration mechanisms, even
information within the sender-auth-header draft, is not especially
helpful in assuring clarity. Proponents of Sender-ID compare path
registration mechanisms to that of a telephone's Caller-ID as a means
to indicate who originated a message. A website by a well known
Redmond vendor describes Sender-ID as follows (capitalization added
for emphasis):
"The Sender ID Framework is an e-mail AUTHENTICATION technology
protocol that helps address the problem of spoofing and phishing by
VERIFYING the DOMAIN NAME FROM WHICH e-mail messages are sent". "SIDF
has been APPROVED by the Internet Engineering Task Force to help
increase the detection of deceptive e-mail and to improve the
deliverability of legitimate e-mail. SIDF is an e-mail AUTHENTICATION
protocol designed to be implemented at no cost for all senders,
independent of their e-mail architecture."
The experimental RFC4406 "Sender-ID: Authenticating E-Mail" also states:
Section 2 Problem Statement:
---
The PRA version of the test seeks to AUTHENTICATE the mailbox
associated with the most recent introduction of a message into the
mail delivery system.
...
In both cases [referring to the PRA and to SPF's MailFrom], the domain
associated with an e-mail address is what is AUTHENTICATED; no attempt
is made to AUTHENTICATE the local-part. A domain owner gets to
determine which SMTP clients speak on behalf of addresses within the
domain; a responsible domain owner should not authorize SMTP clients
that will lie about local parts.
---
The truth is Sender-ID is NOT approved by the IETF as a standard
offering sound guidance to MTA operators! No standardized mechanism
today permits PRA and MailFrrom restrictions without the risk of email
disruption!
Unless impractical restriction are imposed upon all possible PRA
header fields by all outbound MTAs that might carry email by a domain
that might publish SPF records, it is never safe to assert that
Sender-ID's or SPF's authorization of an SMTP client authenticates (or
confirms) which domain originated a message!
The SPF record may have been employed to mitigate back-scatter while
using a shared MTA that imposes no MailFrom or header field
restrictions. The shared MTA may impose access limitations as their
means of control. Since there are no practical means to generally
impose restrictions upon the PRA fields as REQUIRED by the
experimental RFC4406, and the MailFrom as REQUIRED by the experimental
RFC4408, path registration mechanisms at most provide meaningful
results when the SMTP client is NOT authorized. Even then, when an
SMTP client is not authorized, this can not be considered to mean the
message is fraudulent. Often the MTA-NOT-AUTHORIZED state is used to
justify the silent dropping of DSNs.
If it comes to pass that recipients become commonly deceived by
Authentication Results header's nebulous Authentication-Results and
"pass" terms, MTA operators may soon find themselves obligated to
impose universal restrictions upon all possible PRA fields and to
adopt this proprietary algorithm. This makes one wonder whether the
sender-auth-header was clever way to sell the authentication lie.
Perhaps it is just cheaper to pretend something is authenticated. : ^(
Currently, it is unsafe to conclude that a domain even intended to
have Sender-ID applied! This brings into rather serious question what
is meant by the term "Authentication" with respect to either Sender-ID
or SPF.
The path registration mechanism only provides meaningful results when
the SMTP client is NOT authorized. In this case, not accepting a
message may be a reasonable response, but only when one is prepared to
make a significant number of exceptions.
Can authors of these drafts, and the IETF if the drafts become
accepted, dodge being culpable in the deceptive use of the term
"Authentication" and "pass" instead of "MTA-Authorized". The vouch by
reference strategy also assumes all the listed "authentication"
mechanisms equally verify an originating domain. Of course they don't.
Added to this, the sender-auth-header and dac-vbr-headers fail to
capture essential data that will be needed for subsequent reputation
evaluations!
While trace headers are often adjacent, there may be several
intervening MTAs within the receiving administrative domain. The
omission of critical data which might not be normally included within
common trace headers could lead one to conclude that the underlying
goal of these headers is not to improve upon email security. Rather,
the assumption of authentication could be seen as a means to
eventually force the imposition of PRA restrictions into common,
albeit disruptive, practice. This is unfortunate, since DKIM actually
provides a reasonable mechanism to authenticate originating domains
with much less disruption and with far greater security.
To ensure clarity, the kucherawy-sender-auth-header draft should
change its introduction to list the methods as representing either
Authentication or Authorization.
While RFC4406 and RFC4408 describe the state of an SMTP client being
authorized as "pass", to mitigate the significant risk of deceptive
tactics being employed by confidence artists, the "pass" term should
be replaced with the explicit term of "MTA-AUTHORIZED". In addition,
the safest identifier that can be applied in respect to acceptance,
when using path registration, is the SMTP client IP address.
Unfortunately, this IP address is not captured by the sender-auth-
header in these cases. Since the local-part is not verified by path
registration schemes and since local-part macros should be deprecated
to mitigate potential DDoS concerns, the local-part should be excluded
from the header for path registration results as well.
When the method that is being captured is DKIM, the time of reception
should be captured within the header as well. In both cases, the
additional information better enables post process evaluations. For
security reasons, only the portions of the email-address matching
against signature content should be included within the sender-auth-
header. In general, avoid use of misleading terminology or unverified
information.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf