| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 11, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
The proposed [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) defines a header field used to capture email verification results of border receptions. These results are then conveyed to Mail User Agents (MUA) and downstream filters. This header field is to augment filtering decisions and message annotations that can be made visible to recipients. The annotations could affirm originating domains or content integrity when based upon Domainkeys or DKIM results, or a domain's authorization of a publicly transmitting SMTP client IP address when based upon Sender-ID or SPF results, or that the SMTP client IP address maps to a matching domain within the DNS reverse namespace.
Although the draft acknowledges the conflation of authorization with authentication in section 1.5.2, and explicitly declares Sender-ID and SPF as the authorization of the transmitting SMTP client, it still fails to offer the authenticated entity being trusted in the exchange, the IP address of the SMTP client. An authenticated entity is essential for reputation assessments which section 4.1 indicates should be made prior to results being revealed. A reputation check is often a necessary step to mitigate abuse and fraud. Even so, the header offers no assurance that any reputation check has been made, nor does it ensure that the trusted entity, the IP address of the SMTP client, can be determined by the MUA or downstream filter.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
2.
Why hide the IP address of the SMTP client?
3.
IPv6, SPF macros, and local-parts
4.
Recommended Modifications
5.
IANA Considerations
6.
Security Considerations
7.
References
7.1.
References - Normative
7.2.
References - Informative
§
Author's Address
| TOC |
[I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) 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 [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) 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.
| TOC |
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.
| TOC |
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.
| TOC |
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 [RFC3513] (Hinden, R. and S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture,” April 2003.), 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.
| TOC |
This document requires no IANA consideration.
| TOC |
This draft intends to describe serious security concerns raised by the [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) draft. The contained recommendations are expected to reduce the security concerns.
| TOC |
| TOC |
| [I-D.kucherawy-sender-auth-header] | Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” draft-kucherawy-sender-auth-header-20 (work in progress), January 2009 (TXT). |
| TOC |
| TOC |
| Douglas Otis | |
| Trend Micro, NSSG | |
| 10101 N. De Anza Blvd | |
| Cupertino, CA 95014 | |
| USA | |
| Phone: | +1.408.257-1500 |
| Email: | doug_otis@trendmicro.com |