draft-kucherawy-sender-auth-header and last call draft-hoffman-dac-vbr-04

[Douglas Otis <[e-mail]>]

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 [e-mail]", a reasonable  
person should expect this gives recipients the impression that "my- 
trusted-isp.com" has confirmed that the message originated from "[e-mail] 
."

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf