Skip to main content

Authentication-Results Header Field Appeal (Douglas Otis, David Rand; 2009-02-16) / Withdrawn by Submitter - 2009-02-16
Appeal - 2009-02-16

Authentication-Results Header Field Appeal
D. Otis
D. Rand
Trend Micro, NSSG
February 16, 2009

The proposed [I-D.kucherawy-sender-auth-header] defines a header to
capture email verification results obtained at border receptions has
been approved for publication. However, serious deficiencies remain
in its secure use and has prompted an appeal of the publication
decision. This new header field is to convey to Mail User Agents
(MUA) and downstream processes the verification results that are
intended to augment handling decisions and message annotations that
might be made visible to recipients. For such use, it is crucial to
include within an "authenticated-results" header, a truly
authenticated identity.

The draft acknowledges that it confuses authorization with
authentication in section 1.5.2. This confusion has lead the draft to
incorrectly elevate the authorization of an SMTP client into the
authentication of an email-address domain. Elevating the
authorization of the SMTP client into the authentication of an
email-address domain incorrectly assumes current email practices
adequately restrict the use of an email-address domain based upon the
originating IP address of the SMTP client. In an era of carrier grade
NATs, virtual servers, aggregated services, and other techniques that
overload the IP address, this assumption is neither safe nor practical.

Although the draft explicitly declares Sender-ID and SPF as the
authorization of the transmitting SMTP client, it fails to offer the
authenticated identity being trusted. A truly authenticated identity
is essential for reputation assessments which section 4.1 indicates
should be made prior to results being revealed. A reputation check of
a truly authenticated identifier is often a necessary step needed to
mitigate fraud and abuse. In addition, it is unfair to attribute
fraud or abuse to the unauthenticated identifiers. Even so, the
header offers no assurance that any reputation check has been made,
nor does it ensure that an authenticated identity, the IP address of
the SMTP client, can be determined by the MUA or downstream process.
The goal of the appeal is to ensure adequate information is available
when annotating email.

Table of Contents

  1. Introduction
  2. IPv6, SPF macros, and local-parts
  3. Recommended Modifications
  4. References
    4.1. References - Normative
    4.2. References - Informative
    Authors' Addresses

  5. Introduction

In the requested review of [I-D.otis-auth-header-sec-issues], 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 ''.").

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 [RFC4406] 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 [RFC4408]
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 [I-D.kucherawy-sender-auth-header] 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.

[I-D.kucherawy-sender-auth-header] 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 [I-D.kucherawy-sender-auth-header] 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.

  1. IPv6, SPF macros, and local-parts

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.

  1. Recommended Modifications

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 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 [RFC3513],
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.


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.

  1. References

4.1. References - Normative

Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
draft-kucherawy-sender-auth-header-20 (work in progress),
January 2009.

Otis, D., "Authentication-Results Header Field Security
Issues", draft-otis-auth-header-sec-issues-00 (work in
progress), January 2009.

4.2. References - Informative

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.

[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.

[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.

[RFC4870] Delany, M., "Domain-Based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
May 2007.

[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.

Authors' Addresses

Douglas Otis
Trend Micro, NSSG
10101 N. De Anza Blvd
Cupertino, CA 95014

Phone: +1.408.257-1500

David Rand
Trend Micro, NSSG
10101 N. De Anza Blvd
Cupertino, CA 95014

Phone: +1.408.257-1500