Douglas Otis wrote:
Standardizing on border-check header results is of importance only for
path registration schemes. These headers reduce the security obtained
by signature based schemes since these border-check headers depend
heavily upon uncertain handling given the new headers when entering an
administrative boundary. In addition, bad actors are rather notorious
at obtaining access to MTAs internal to an administrative domain. A
further reduction in security has been created by the choice of the
header-label and the method states. The label and states are well
designed to MISLEAD users into believing that an email-address had
been AUTHENTICATED when it has not!
Doug, the sky isn't falling. I think you're creating a crisis where
none exists.
There's been ample consensus that the current format is acceptable, as
is evidenced by its adoption at some large-scale ISPs that serve many
thousands of users. The current draft is the product of over two years
of collaboration on this mailing list. Clearly there is very little
concern about users being misled by the syntax and semantics in the draft.
The draft has been reviewed by the Security Directorate. The reviewer
had no voiced concerns about the name of the header field.
The draft states very clearly, even in its abstract, that it is only
relaying information found at the border MTAs. The draft further states
that it is not establishing any value with the results, only relaying
them. That's its only purpose, and it is explicit. It's up to the
consumers of that information to make decisions about its safety by
understanding what's being claimed, and that too is spelled out in the
draft.
That the authentication methods whose results are being relayed could
themselves be subverted is already acknowledged in the Security
Considerations. The header field's consumer is thus encouraged to be
aware of those risks.
That the use of "Authentication" in the header field's name could be
claimed as misleading with respect to schemes that are arguably only for
authorization (a vauge concept, as Dave Crocker already discussed) has
not been an impediment or concern to the implementation or utility of
the draft by any party that has implemented it thus far. Moreover, the
draft is not explicitly relaying any sort of claim about what data was
authenticated; the data you keep citing merely reflect what the key
inputs to the performed algorithm were. And further still, the draft
very clearly lays out the meaning of each of the results it relays, even
explicitly using the word "authorization" in some of those descriptions.
If your assertion is that the implications of this header field should
be completely self-evident to end users without consulting any relevant
documentation at all, then I suspect we can quickly invalidate the vast
majority of the published RFC base.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html