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