Last Call sender-auth-header

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 jon(_dot_)doe(_at_)example(_dot_)com

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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf