Authentication-Results Header Field Appeal

In the requested review of , Barry Leiba made the following remarks: In other words, Doug considers that it's the IP address, not the ADMD, that has been "authenticated". I disagree, but this is a tricky area, because we're not wading in a typical sort of authentication pool here -- SPF is actually blending identity, authentication, and authorization. As I see it, the SPF model is that the *identity* to be authenticated is taken from the SMTP MAIL FROM command (for Sender-ID it's derived through the PRA algorithm), the IP address supplies the authentication *credentials*, and the DNS lookup both verifies the credentials (completing the authentication) and returns the authorization information in one, combined response ("the entity with these credentials is authorized to send mail on behalf of the identity 'example.com'."). Lets start with the *authorization* aspect. When evaluating SPF compliance, it is common for virtual SPF records to be used that impose a CIDR range on MX record targets whenever an SPF record is not available. As such, SPF results leave the issue of there being any real *authorization* in doubt. In addition, Sender-ID in section 2 indicates the use of Mail From, in addition to the PRA: On the other hand, the MAIL-FROM version of the test seeks to authenticate the mailbox that would receive Delivery Status Notifications (DSNs, or bounces) for the message. In simple cases, this too is who the mail is from. However, third-party mailers, forwarders, and mailing list servers MUST specify an address under their control, and SHOULD arrange that DSNs received at this address are forwarded to the original bounce address. In both cases, 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. Since Sender-ID permits the use of either version of the SPF records to be applied against the PRA, version 2 records must then be published whenever authorization of a PRA is not intended. This retro-active mandate is to prevent the misapplication of SPF records against PRA header fields. The conflict as to whether just the Mail From or the PRA has been authorized by SPF version 1 records has left the intended scope of the SPF record in doubt. The fails to indicate which version of an SPF record had been discovered, or whether any record had been discovered allowing recipients a means to gauge risk. It is not just whether SMTP clients lie about local-parts, it is whether an IP address ensures only authorizing domains can send the Mail Froms or PRAs containing the authorizing domain. Since such IP address restrictions are not in common practice, nor can such restrictions be assured not to interfere with existing email practices, a premise that SPF authorization implies the authentication of any Mail From or PRA from an authorized SMTP client should be regarded as dangerously ill founded. Including just the email-address domain as being authenticated makes the header deceptive. introduces a header field, which because of its label, can mislead recipients into believing that it contains "Authentication-Results". The use of phrases rather than result codes belies the draft's introductory claim that this header is not intended for direct human consumption. MUAs, such as Apple Mail, are able to directly display this header above a message following minor user accessible setting changes. In the case of Sender-ID or SPF, the deceptive nature of this header could have been remedied by including the "authenticated" IP address of the SMTP client, in addition to the authorizing domain. This IP address must be passed to the SPF record verification process by the receiving MTA, and is essential for either Sender-ID and SPF processing. Only an authenticated identity is able to serve as a safe basis for reputation. A reputation check of the authenticated source is strongly recommended by section 4.1. Without the presence of an authenticated identity within the Authenticated-Results header, there can not be any practical or timely remedy against compromised SMTP client access or BGP spoofing. With hundreds of millions of compromised systems organized into bot-nets, no assumption regarding unauthenticated identifiers should be considered safe. This concern is not about allowing MUAs a means to repeat a verification process, the inclusion of the IP address of the SMTP client is to provide the MUA or downstream process with the authenticated identity that is being trusted to protect the email-address. In the case of Sender-ID or SPF, the identity being trusted to protect the use of Mail From or the PRA is the SMTP client identified by its IP addresses. The places within the that purport either Sender-ID or SPF as authenticating the originating domain overlook the dangerous and misleading assumptions needed to arrive at that conclusion. Just as it would not be safe give someone a negative credit rating based upon transactions not substantiated through some form of authentication, a domain must not be held accountable for incorrect assumptions made by receiving MTAs. Doing so would be highly disruptive, coercive, and unfair. While there are cases where a domain is controlled by a bad actor, often use of the bad domain is brief. Difficulties imposed by Sender-ID or SPF in determining whether a domain originated a fraudulent or abusive message also imposes delays in the assignment of negative reputations. Any delay is likely to make any effort at protection less effective than when using the already authenticated IP address of the SMTP client. Negative reputations based upon the IP address of the SMTP client are fairly common, and many are automated and assigned nearly immediately. Since security is fragile, whenever a server suffers from a security breach, rather than blocking all mail from a domain to mitigate fraudulent messages, assigning a negative rating to an affected SMTP client IP addresses mitigates a problem without completely blocking all messages from the domain. The domain would then be free to issue warning messages regarding the nature of the security breach. Such notification would not be possible if only the reputation of the authorizing domain was expected to serve as a mitigation solution.

When IPv6 becomes more commonly used, white-listing IP addresses will be needed as a solution for dealing with the increased address range. There are currently no practical solutions able to scale to the challenging range of IP addresses that might be controlled by bad actors. This means problems related to IPv6 will result in the removal of white-listed IP addresses. Unlike most DNS resources that segregate IPv4 and IPv6 datasets, SPF consolidates both IPv4 and IPv6 addresses into a common list comprised of a chain of DNS transactions. SPF also includes macros used by recipients that can expand the IP address of the SMTP client into labels used in subsequent DNS queries. Expressing an IPv6 address using the SPF macro in the reverse order nibble form can comprise a query containing more than 32 labels. If the local-part macros are used to locate MX records, the MX targets can comprise a set of 100 separate hostnames. Local-part macros could also be used to chain SPF record sets. Unfortunately, the Authentication-Header draft may actually encourage use of this dangerous local-part macro. Section 2.4.3 requires local-part authentication before it is to be included within the Authentication-Results header. In addition, there is nothing to indicate whether the local-part played a role in obtaining SPF results. The danger imposed by the use of the local-part macro is inherent in the query required to support both an IPv6 expansion, in conjunction with the expansion of local-part macros induced by possibly cached SPF records. The local-part, along with a range of IP addresses made readily possible by IPv6, can be manipulated to induce a flurry of large DNS transactions directed toward any otherwise uninvolved domain, all directed by cached DNS records. The SPF local-part macro would allow a cached DNS record to be repeatedly exploited by a spam campaign without the attacker consuming any of their additional resources beyond that used to send their spam campaign. It is never a good idea to allow free attacks. The previous draft regarding the SPF DoS concern was never fully understood, nor was the basis of the concern acknowledged by SPF proponents. Logically, local-part macros would not safely provide a positive result without the query also being combined with the IP address list of authorized SMTP clients in some form. This means an address list structure would need to be repeated for each of the domain's users. Rcpt To provides a simpler, lower overhead, and more expedient way to determine whether a NDN should be returned without the risk associated with SPF's active content being placed within DNS resource records. Several parsers ignore local-part macro expansion since they rarely play any role in providing positive results. The typical target of a DDoS attack is often not the email-providers that might enable the attack. Often attacks are directed toward those attempting to mitigate abuse by issuing the status of a range of IP addresses. Since these protective services may have been problematic for the providers, there exists a level of animosity toward what may appear to be conflicting goals.

Change Section 2.4.3 FROM: If the retrieved sender policies used to evaluate [SPF] and [SENDERID] do not contain explicit provisions for authenticating the local-part (see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported along with results for these mechanisms SHOULD NOT include the local-part. TO: To discourage exploitation risks, the entity that has been authenticated (the IP address of the SMTP client) SHOULD BE included. The "pvalue" reported along with results for these mechanisms SHOULD NOT include the local-part, but instead the local-part SHOULD BE replaced with the IP address used to evaluate the SPF record after being converted to a string using conventional dotted quad notation for IPv4, or the 16 bit hexadecimal notation defined by , section 2.2, and terminated by the "@" symbol. Change Section 4 FROM: End users making direct use of this header field may inadvertently trust information that has not been properly vetted. If, for example, a basic [SPF] result were to be relayed which claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated. Thus, an MTA adding this header field SHOULD NOT include any data which has not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it. TO: End users making direct use of this header field may inadvertently trust information that has not been properly vetted. [SPF] results SHOULD BE handled as specified by section 3.4.3. In general, an MTA adding this header field SHOULD NOT include any data which has not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it. An exception is to be made for an Authorizing domain only when it accompanies the authenticated IP address of the SMTP client.

This document requires no IANA consideration.

This draft intends to describe serious security concerns raised by the draft. The contained recommendations are expected to reduce the security concerns.