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

Douglas Otis wrote:
> 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(_dot_)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".
I suggest that the Technological sense of Authentication is irrelevant 
here. The real issue is what the Court's and those stuck using these 
protocols are forced to do to prove their actions. As such its the 
Court's Authentication Schema's that should be relied on here rather 
than what we as technologists would prefer.
> 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.
Except that there is no way with the proposed model to prove that IP 
address is accurate and not being spoofed.
> 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. 
The IETF is a steward of nothing. Its a Standards Platform and 
management process to create 'open and fair' internet standards.
> We all know there is money to made picking up the pieces, but there 
> are more productive ways to make a living.
> -Doug _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM
>   
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf