ietf
[Top] [All Lists]

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

2008-11-06 23:01:57
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(_at_)example(_dot_)com", a reasonable person should expect this gives recipients the impression that "my- trusted-isp.com" has confirmed that the message originated from "jon-doe(_at_)example(_dot_)com ."

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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • draft-kucherawy-sender-auth-header and last call draft-hoffman-dac-vbr-04, Douglas Otis <=