Subject: Last Call sender-auth-header

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Nov 2008 20:00:36 -0800

Last call for
  http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-17.txt
The intent of this posting is to generate broader discussion.

Browser and MUA plugins may soon annotate email messages with  
identifiers contained within Authentication-Results headers.  For  
Apple Mail, just setting changes can cause this header to be displayed  
above the message.  The reason given for the Authorization-Results  
header is stated in section 1 Introduction:
,---
The intent is to create a place to collect such data when message  
authentication mechanisms are in use so that a Mail User Agent (MUA)  
can provide a recommendation to the user as to the validity of the  
message's origin and possibly the  integrity of its content.
'---

There is an essential consideration when using this header given in  
section 4.1 Header Position and Interpretation
,---
An MUA SHOULD NOT reveal these results to end users unless the results  
are accompanied by, at a minimum, some associated reputation data  
about the message that was authenticated.
'---

This statement would have been more clearly stated as:
,==
An MUA SHOULD NOT reveal these results to end users unless the results  
are accompanied by, at a minimum, some associated reputation data  
about the authenticated origination identifiers within the message.
'==

This consideration is to preclude the apparent endorsement whenever  
authenticated identifiers have obtained negative reputations.  In  
addition, only authenticated identities are safely assigned negative  
reputations. Therefore, it is extremely important to understand what  
authentication means, and which identifiers can be authenticated.  In  
addition, since reputation results are not included in this header,  
and there is no assurance reputations have been checked.  The Browser  
and MUA plugins will need to obtain reputations for these identifiers  
independently to comply with section 4.1.

With respect to Sender-ID, the auth-header draft and author presume  
the PRA email-address captured within the Authentication-Results  
header will be considered authenticated whenever the sending MTA is  
authorized by the SPF record located by PRA.  This authorization, as  
the draft states, is denoted by "sender-id=pass".  A presumption of  
the PRA being authenticated expects there will be PRA restrictions  
imposed by all SPF authorized MTAs.  A presumption of PRA  
authentication is why the weakly authenticated IP address of the SMTP  
client that was authorized by the SPF record is omitted.

Section 1.3  Definitions says:
,---
Generally it is assumed that the work of applying message  
authentication schemes takes place at a border MTA or a delivery MTA.   
This specification is written with that assumption in mind.
...
It is also possible that message authentication could take place on an  
intermediate MTA.  Although this document doesn't specifically  
describe such cases, they are not meant to be excluded from this  
specification.
'---

The position of the Authentication-Results header, with respect to the  
Received header added by the border MTA, is unknown.   Browser and MUA  
plugins will be required to guess which Received header was added by  
the border MTA, but even then, the Received header is not assured to  
include the IP address of the SMTP client.

As such, the auth-results draft clearly expects that the SMTP client's  
reputation plays no role.  Reputations are to be based only upon the  
PRA when applying annotations. : ^(

It is rather startling that adoption of an experimental RFC is being  
presumed by this draft.  As such, those not adopting this experimental  
PRA RFC run the risk of being assigned a negative reputation, or of  
misleading those believing PRA are authenticated as a result of this  
misleading header.  In addition, although SPF includes local-part  
macros that might invite DDoS attacks, these seldom used macros can  
only deny and not affirm the validity of a domain's local-parts.

With respect to reputation in regard to SPF or Sender-ID, it is _only_  
the IP address of the SMTP client seen by the border MTA that has been  
weakly authenticated.  Unfortunately, the authentication-results  
header has neglected to include this SMTP client IP address.  This  
omission might have been to mislead recipients into believing PRAs are  
authenticated, or to force adoption of PRA restrictions, or to deflect  
the affect of abusive behavior.  For example, it is common to see less  
scrupulous ad campaigns or perhaps compromised servers emit abuse from  
specific IP addresses.  Blocking all email that carry a specific  
domain seldom represents a measured or practical response to a problem  
isolated to specific servers.  As such, the favorable annotation of  
spam may occur, or one compromised server may disrupt email from the  
entire domain.

Blocking only servers that appear abusive would be far less disruptive  
than blocking by the domain.   An assumption that a PRA has been  
authenticated whenever a Sender-ID pass result is obtained assumes all  
SPF authorized MTAs impose PRA restrictions for all email they carry.   
This also means any litigation against the holder of the PRA IP could  
then force those defending their own IP into not imposing these now  
essential PRA restrictions.   No effort has been made to note when  
only SPF records have been published.  But of course, such  
notification would call into question the expectation of PRA  
restrictions being imposed.  :^(

Adoption of this draft may then require the IETF to endorse Sender- 
ID.  After all, email providers would rather have domains blamed for  
abuse, than the IP address of their MTA when failing to restrict  
access to bad actors using forged identities.  DKIM seems like a far  
safer solution, since it does offer a valid means to authenticate the  
domain.

This draft can be repaired by making minor changes.  This can be done  
by having the content of the Authentication-Results header read:

  my-isp.com;  sender-id=pass MTA/10.100.200.2/Authorized-by/ 
@example.com

rather than:

  my-isp.com;  sender-id=pass [email-masked]

Both security and clarity is achieved without violating what this  
string is allowed to contain.  There are no reasons that respect the  
security of the individual for not to making this change.

-Doug

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Fri, 21 Nov 2008 11:02:27 -0800

At 20:00 20-11-2008, Douglas Otis wrote:
>presumed by this draft.  As such, those not adopting this 
>experimental PRA RFC run the risk of being

There are existing implementations of these experimental RFCs.

>Adoption of this draft may then require the IETF to endorse 
>Sender-ID.  After all, email

As I mentioned before on the mail-vet mailing list, this header is 
used to convey results of DomainKeys, DKIM, SPF and Sender-ID 
evaluation.  It is not an endorsement of a specific evaluation method.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Nov 2008 17:42:26 -0800

On Nov 21, 2008, at 11:02 AM, SM wrote:

>> It is rather startling that adoption of an experimental RFC is  
>> being presumed by this draft.  As such, those not adopting this  

Sorry, this should have said "universal adoption".

The sender-auth-header draft states  "as to the validity of the  
message's origin" and describes both Sender-ID and SPF as "e-mail  
authentication methods in common use".  When SPF records are published  
to mitigate MailFrom backscatter,  it is not reasonable to assume  
authorized MTAs restrict MailFrom to only authorizing domains.  There  
is _nothing_ to indicate MTAs require authorization and then bind  
authorizations to specific domain controlled accounts.   Whether  
restrictions are imposed on PRAs or MailFroms based upon  
authentication-results headers for Sender-ID and SPF represents highly  
speculative and highly dangerous conjecture.  Since these identities  
can not be authenticated in this manner, it would be perilous to  
assign negative reputations against these speculative domains as well.

While a lack of authorization might form a basis to refuse acceptance  
or to decide folder placement, there are no practical conventions,  
experimentally or otherwise, that supports this draft's presumption of  
authentication for either SPF or Sender-ID.  The only (weakly)  
authenticated identifier is the IP address of the SMTP client seen by  
the border MTA, whether this SMTP client was authorized by Sender-ID  
or SPF or not.  This information, which is essential to assess and  
assign reputation, has been omitted!  The IETF should seriously  
question the motives for such omission.

>> ID.  After all, email

The typical user will see this header making the following statement--

Authentication-Results: myisp.com; sender-id=pass [email-masked]

A reasonable person who understands the definition for authentication  
will be mislead into believing they are being assured by "myisp.com"  
that "[email-masked]" originated the message.

For either SPF or Sender-ID, an assumption of authentication requires  
universal adoption of both MailFrom AND PRA restrictions by ALL  
authorized MTAs.  Omitting the only "authenticated" identifier  
associated with either of these methods helps sell the lie that SPF or  
Sender-ID are authentication methods.  Since there is not universal  
adoption of MailFrom and PRA restrictions by all authorized MTAs for  
both Sender-ID and SPF, this lie can act as a type of extortion.

Those mislead by this header will be even more prone to confidence  
artists.  Confidence artists can now take advantage of current email  
infrastructure that does not impose the experimental restrictions and  
have their message receive misleading endorsements made possible by  
this header.  Perhaps creating this problem is seen as a means to  
drive demand for MTAs that can bind PRA and MailFrom restrictions  
against validated accounts.  Although such efforts are likely  
impractical in many cases, there is no way to "opt-out" other than not  
publishing SPF records.   Since many may depend upon SPF to mitigate  
backscatter from larger providers, removing the local-part, adding the  
IP address of the SMTP client, and the term "authorized-by" is a  
reasonable solution that is much less likely to prove misleading.   
Unless of course, the desire is to mislead?  Having the IP address  
available permits access to automated reputation assessments that have  
a reasonable chance at providing timely protection, unless of course  
the desire is not to offer protection?  Protecting against just look- 
alike attacks likely represents a manual and slow process.

-Doug