Authentication-Results Header Field Security Issues

introduces a header field, which because of its label, might potentially mislead recipients into believing that it contains "Authentication-Results". Common phrases such as "Authentication-Results", "pass", "fail", and "senderid" rather than the use of 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 can be greatly 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. After all, a reputation check of the authenticated source is strongly recommended by section 4.1. The scope of the Authentication-Results header per section 1.3 states: This proposal is to address the needs of authenticating messages or properties of messages during their actual transport. However, the scope of the SPF record, such as whether the Mail From or the PRA are the intended authorization identifiers, or whether these identifiers are exclusively controlled by the authorizing domain, remains unknown. Although the specification for the SPF version 1 record conflicts with that of Sender-ID regarding which identity can offer authorization, whether a version 2 record was used is not tracked by Sender-ID. This means the results returned by Sender-ID leave the intent of Mail From or the PRA use unknown. In addition, although access to outbound SMTP servers may be limited, restrictions may not have been imposed upon the use of the Mail From or the PRA. A strategy to control abuse might rely upon rate limits and access denial subsequent to reports of abuse. The reasons for publishing SPF records could have been to mitigate backscatter, where loss of some Non-Delivery-Notifications (NDNs) was considered acceptable. The intent may not have been to offer a positive basis for identification, but instead their expectations may have been that negative results would limit the number of invalid NDNs. Evidence of this intent might be denoted by SPF records ending with "?all", for example. With hundreds of millions of compromised systems organized into bot-nets, no assumption regarding unauthenticated identifiers should ever be considered safe. For example, assume a domain, using a version 1 SPF record, authorized a provider to handle outbound email with an understanding that their Mail From is to be bound to authenticated accounts controlled by only their domain. Even so, controlling the Mail From will not prevent another inbound provider from assuming a PRA found in a message has also been bound exclusively to accounts controlled by the domain, even when there is little justification to assume that this arrangement exists. Although the experimental SPF specification warns against making this assumption, the experimental Sender-ID specification permits the application of version 1 records against the PRA. 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 imposes delays in the assignment of negative reputations. Any delay is likely to make protections far 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 affected SMTP client IP addresses mitigates the 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.

It has been claimed by the author that including the IP address of the SMTP client is out of scope. However, one might just as easily argue that only authenticated identities should be considered within scope of an "Authentication-Results" header. Although the past four years has seen a barrage of marketing efforts that repeatedly and erroneously describe Sender-ID as authenticating the originating domain of a message, this would be making an assumption that fully trusts the SMTP client to have bound the use of either the Mail From or the PRA to accounts exclusively controlled by the authorizing domain. There will be cases where imposing this binding is not practical, nor kept in compliance with the standard specifications. Any stipulation of authentication would therefore exclude the listing of authorizing domains, in favor of the IP address of the SMTP client. A fair compromise would be to include both. Influential proponents of Sender-ID and SPF include large providers, whose clout is increased by having their mail-stream represented by a single identifier, their domain. Having acceptance or annotations based solely upon the authorizing domain, rather than also including an IP addresses they control, is understandable, but is fairly short-sighted. Only relying upon the authorizing domain makes dealing with security more difficult, and places customers at much greater risk. Providing an allusion of security greatly benefits confidence artists who will have no trouble exploiting the difference between authorization and authentication.

When IPv6 becomes more commonly used, white-listing IP addresses will likely 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. 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 this 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 the SMTP clients in some form. The list structure would need to be repeated for each of the 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 active content placed within DNS resource records. Several parsers ignore local-part macro expansion since they rarely play any role in providing positive results.

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 created by a seldom used local-part authentication feature provided by SPF, and to lessen the misleading appearance that only providing the domain represents, 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.