[mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header

[Douglas Otis]

On Jan 9, 2009, at 12:48 PM, Lisa Dusseault wrote:

> Hi Doug,
>
> Does anybody support your review of sender-auth-header, to the point  
> of believing that the document should not be published?  So far you  
> are still very much in the rough part of rough consensus.
>
> thanks,
> Lisa
>
> On Wed, Jan 7, 2009 at 1:14 PM, Douglas Otis <dotis at mail-abuse.org>  
> wrote:
>
>> Murray,
>>
>> There has been progress, but a few extremely critical security  
>> related areas still need to be addressed.
>>
>> I have posted a draft that reviews the sender-auth-header draft.
>>
>> The text and html versions are available at:
>>
>> http://www.ietf.org/internet-drafts/draft-otis-auth-header-sec-issues-00.txt
>> http://www.sonic.net/~dougotis/id/draft-otis-auth-header-sec-issues-00.html

Funny that you describe your concern as involving rough consensus.   
The draft itself can't decide when it should stop pretending about  
what defines authentication, and remains remains contradictory on this  
critical subject.

It states that only _authenticated_ information should be included  
within the "Authentication-Results" header for either Sender-ID or  
SPF.  At the same time, the draft defines Sender-ID and SPF as being  
an authorization method and _not_ the authentication of the domain.    
In fact, there is no way to know whether Sender-ID results were based  
upon SPF version 1 records in its current form, or whether a domain  
even intended positive results to affirm its identities, or whether  
just negative results of a Mail From were intended to mitigate back- 
scatter.  This leaves the issue of authentication itself clearly in  
the rough.

In addition, there is also the matter of encouraging the use of  
dangerous local-part macros when one wishes to obtain email-address  
annotations.  At least the Sender-ID specification states local-parts  
are _not_ verified.  What is providing the authorization remains  
unknown for SPF, even though the local-part is ignored in Sender-ID.   
In addition, there is no consensus between either Sender-ID or SPF as  
to which elements of a message are to be used to access version 1  
records.  Clearly, scoping issues are also in the rough.   
Nevertheless, this header is willing to label results of this mess  
"Authentication-Results".

The remedy being sought is to replace the local-part of the  
"authorizing" email-address with a converted string representing the  
IP address of the SMTP client that is being authorized.  This allows  
the authenticated origin of a message to be vetted, in addition to  
what _might_ be an authorizing domain.  A fair compromise.

While there are influential proponents of this draft, this draft and  
the experimental SPF and Sender-ID RFCs remain dangerous as written.   
With a few minor modifications, the Authentication-Header draft would  
become much safer.  Satisfying those that represent influential  
special interests should not cause the IETF to dismiss their  
stewardship role.   We all know there is money to made picking up the  
pieces, but there are more productive ways to make a living.

-Doug