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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx> 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@xxxxxxxx
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]