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