On Feb 19, 2009, at 6:04 PM, Dave CROCKER wrote:
The IESG wrote:
The IESG has received an appeal regarding the previously approved
draft-kucherawy-sender-auth-header-20. The appeal text can be
found here:
http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
This note offers comments on the appeal, draft-otis-auth-header-
appeal-00, which has been lodged against standardization of draft-
kucherawy-sender-auth-header-20.
This appeal lacks merit on basic points.
As a technical criticism, the appeal is confused and lacks
substance. The conclusions appear to be based on fundamentally mis-
reading of basic technical details of the specification. At best,
the appeal makes the mistake of wanting to kill the messenger,
rather than the message's author. That is, the appeal's authors
appear to have concerns with certain types of report content, rather
than with the mechanism of doing reporting. Yet auth-res is merely
the mechanism, a common conduit for reporting a class of related
information.
Dave,
Section 4.1 of this draft places the onus of checking associated
reputations of "authenticated origin identifiers" on the MUA prior to
revealing the content of the Authentication-Results header, but then
fails to offer the necessary information for satisfying this
requirement. Unfortunately, this draft's many confusing references to
authorization mechanisms as authentication still does not offer, with
any reasonable certainty, that an authorizing domain originated a
message. The only weakly "authenticated origin identity" for either
SPF or Sender-ID is the IP address of the SMTP client being authorized
by an SPF record. When the SPF-SMTP-client authorization schemes were
introduced, a client's failure to be authorized was to provide a basis
for not accepting the message.
Indeed, the appeal is dominated by criticisms of SPF and Sender-ID.
The appeal's authors should express their concerns with those
communities of interest, rather than with a mechanism that merely
carries information that is generated by other mechanisms.
The appeal attempts to clarify that *authorization* does not represent
*authentication*. An authenticated SMTP client does not imply that
it is authorized to issue a domain's message, neither does an
authorized SMTP client imply that a domain offering authorization has
therefore originated the message. It is the origin of the message
and its role in protecting originating identifiers that is being
trusted. The reputation of the "authenticated origin identity"
ensuring this protection is what MUAs should depend upon. Look-alike
attacks should not be accepted by border MTAs, but can still be
thwarted proactively by the MUA with folder placement.
As a statement of preference, the appeal lacks support. Contrary to
the appeal authors' perspective, the bulk of the email reporting
operations community find this mechanism helpful, in its current
form. Whatever possible downsides the appeal's authors envision, it
has not yet come to pass, over a long period of use.
A desire to exclude the IP address of the SMTP client is likely aimed
at avoiding repercussions that occur when issuing abusive messages.
Rather than the reputation of a provider's ability to protect the use
of a domain, the domain instead is expected to accrue the negative
reputations. Unfairly assigning negative reputations to a domain not
originating abusive messages can be disruptive and may invite
litigations.
Detailed comments follow:
For such use, it is crucial to include within an "authenticated-
results" header, a truly authenticated identity.
Auth-res is specified as operating within a trust domain. It
explicitly asserts the need for trusting the source of the report
and the path from the report generator to the report consumer. As
such, there is no obvious basis for claiming that further
authentication of the report is needed.
Section 4.1 correctly provides a basis for needing the "authenticated
origin identifier". *Authorization* is not *authentication*.
The draft acknowledges that it confuses authorization with
authentication in section 1.5.2.
No it does not. There is no language in 1.5.2 that describes or
acknowledges any confusion. The only relevant text in that section
is "this proposal groups them both into a single header field".
Please review section 1.5.2 and then the many places where
*authorization* is then referred to as *authentication*. The draft
places all results into a header labeled "Authentication-Results"
where the only identifier offered is that of the authorizing domain,
and not that of the authenticated IP address of the SMTP client for
Sender-ID or SPF.
Consequently it appears that the real confusion is with the authors
of the appeal, who confuse an explicit decision to allow two types
of information to cohabit, with inability to distinguish between the
two types of information.
The concern is over the explicit decision to exclude the authenticated
SMTP client identifier in lieu of a domain offering authorization "as
if" it represents an *authenticated* identifier. Providers using this
omission to elude accountability for issuing abuse will imperil
recipients with misleading information. This omission leaves
recipients more prone to confidence schemes that might be aimed at
inviting recipients to open malware or reveal credentials.
This confusion has lead the draft to incorrectly elevate the
authorization of an SMTP client into the authentication of an
email-address domain.
This language implies (or states directly) that the subject
specification is performing authorization and/or authentications
functions. The spec does nothing of the sort. It conveys
information, about functions performed by supplying mechanisms.
It's only active function, beyond that, is to map some information
into canonical form. If the appeal's authors are claiming that this
mapping function somehow turns authorization information into
authentication information, they need to supply the particulars.
The mapping intentionally excludes authenticated input information
that will be lost. This information forms the basis for the mechanism
being reported. The MUA is required by the draft to check the
reputation of the authenticated identifier, the IP address of the SMTP
client. There is no other way to regenerate this information at the
MUA. Nor is there an out-of-band mechanism which can reliably pass
this information. If the author of draft-kucherawy-sender-auth-
header knows of such a mechanism, it should be included in the draft.
Depending upon headers that are not signed, not validated, and
impossible to trust is not workable. This issue is not about whether
to block a message, it is about whether to reveal this header's results.
More likely, the appeal's authors need to distinguish report
conveyance from report generation. They need to pursue their
concerns about particular message security analysis functions with
the folks responsible for particular functions, whether path
registration based, message authentication crypto-based or whatever
particular services they are actually unhappy with.
The concern in this case is with the exclusion of essential and
necessary input information by the reporting mechanism. The omission
is input information passed to the authorization mechanism. The
exclusion of this information is not the fault of the authorization
mechanisms, as is being suggested.
Elevating the *authorization* of the SMTP client into the
*authentication* of an email-address domain incorrectly assumes
current email practices adequately restrict the use of an email-
address domain based upon the originating IP address of the SMTP
client. In an era of carrier grade NATs, virtual servers,
aggregated services, and other techniques that overload the IP
address, this assumption is neither safe nor practical.
Although the draft explicitly declares Sender-ID and SPF as the
authorization of the transmitting SMTP client, it fails to offer
the authenticated identity being trusted.
The draft does not make that declaration. It states that Sender-ID
and SPF make that declaration. Again, confusing message with
messenger.
The issue is not about what Sender-ID or SPF declare, the concern is
about vital information being omitted by this draft.
A truly authenticated identity is essential for reputation
assessments which section 4.1 indicates should be made prior to
results being revealed.
I don't understand what significance this statement has.
It would be a bad practice to assign reputations based upon the
actions of others. When a domain authorizes an SMTP client (it
remains uncertain if such an authorization had been made), it would be
an unfair practice to impact the reputation of these domains for
messages they may not have originated. The issue is strictly the
concealment of the authorization inputs.
Concerning this following portion of the appeal:
1. Introduction
In the requested review of [I-D.otis-auth-header-sec-issues], Barry
Leiba made the following remarks:
...
Since Sender-ID permits the use of either version of the SPF
records to be applied against the PRA, version 2 records must then
be published whenever authorization of a PRA is not intended. This
retro-active mandate is to prevent the misapplication of SPF
[RFC4408] records against PRA header fields. The conflict as to
whether just the Mail From or the PRA has been authorized by SPF
version 1 records has left the intended scope of the SPF record in
doubt.
It has no discernible relevance to the auth-res specification. At
best, it has some relevance to mechanisms that produce output that
is carried by auth-res. The appeal's authors should therefore
address their concerns with the relevant specifications and
authors. Auth-res isn't the venue for this.
Raising this issue was to clarify the point that *authorization*,
especially uncertain authorization, is NOT *authentication*. An
"authenticated origin identity", as required by the draft, is
essential for fair and safe assessments prior to revealing this
header's results.
The [I-D.kucherawy-sender-auth-header] fails to indicate which
version of an SPF record had been discovered, or whether any record
had been discovered allowing recipients a means to gauge risk.
Auth-res carries the information it is given. If SPF or Sender-ID
should report different information, the appeal's authors should
discuss this with the SPF and Sender-ID community.
The header omits the essential *input* given to SPF or Sender-ID
processes. The issue of omission pertains only to the Authentication-
Results draft.
[I-D.kucherawy-sender-auth-header] introduces a header field,
which because of its label, can mislead recipients into believing
that it contains "Authentication-Results".
The appeal's authors have nicely demonstrated that almost anything
can be confused. So an abstract fear of possible, future confusion
is a pretty weak argument for (or against) anything.
It is both the label and the omission of essential information that is
dangerously misleading.
In the case of Auth-res, there is already an established track
record, with no indication that the feared confusion due to the
header field's name, has occurred.
The concern is over the lack of protection that the omission of
essential information creates. There is a fairly long track record of
recipients and MUAs being mislead.
In addition, as a matter of simple vocabulary semantics, the chosen
field name accurately represents the role this carried information
plays.
A field named "senderid" does not in any way indicate an authorization
role. Roles would be less confusing had the input information not
been omitted.
Without the presence of an authenticated identity within the
Authenticated-Results header, there can not be any practical or
timely remedy against compromised SMTP client access or BGP spoofing.
At best, the appeal's authors are confusing a possible need for
independent authentication, between report creator and report
consumer, with the contents of the report itself. Auth-res
specifies the report contents. If the appeal's authors are concerns
about authenticating the contents, they should pursue a separate
specific and garner support for it.
The issue is about omitting input given to the authorization process.
After all, it is the SMTP client identified by its IP address that is
trusted to protect the use of the email-addresses referencing the
authorization.
The places within the [I-D.kucherawy-sender-auth-header] that
purport either Sender-ID or SPF as authenticating the originating
domain overlook the
Auth-res "purports" nothing of the kind.
Section 2.4.3 includes an example. Here the sender-auth-header draft
purports that SPF or Sender-ID as offering not just authenticated
domains, but also authenticated local-parts!
,---
If the retrieved sender policies used to evaluate [SPF] and [SENDERID]
do not contain explicit provisions for authenticating the local-part
(see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported
along with results for these mechanisms SHOULD NOT include the local-
part.
'---
2. IPv6, SPF macros, and local-parts
Linking IPv6 with Auth-Res is creative, but spurious.
The draft's requirement to exclude the local-part unless
"authenticated" represents an incentive to use a dangerous mechanism,
as well as incorrectly purporting this to be authenticated.
Unfortunately, the Authentication-Header draft may actually
encourage use of this dangerous local-part macro. Section 2.4.3
requires local- part authentication before it is to be included
within the Authentication-Results header.
The relevant language in the spec prohibits including a field, in an
authentication report, if it has not been authenticated. All that
that encourages is authentication. Extrapolating that requirement
into encouraging
use of that field is without basis or merit.
It is rather naive to expect senders will not seek greater prominence
that might be achieved with a greater amount of annotation.
3. Recommended Modifications
Change Section 2.4.3 FROM:
...
TO:
To discourage exploitation risks, the entity that has been
authenticated (the IP address of the SMTP client) SHOULD BE included.
This fundamentally changes the meaning of that section of the
specification and, instead moves into active role in the internals
of the reporting mechanism.
Including the only authenticated origin identity used as an input to a
mechanism should not be considered in any way internal to that
mechanism. This is not any different from that of the "iprev"
mechanism. Unfortunately, the "iprev" mechanism may impose excessive
overhead due to nature of the reverse namespace.
TO:
End users making direct use of this header field may inadvertently
trust information that has not been properly vetted. [SPF] results
SHOULD BE handled as specified by section 3.4.3.
This is the same confusion of venues as cited above.
The Authentication-Results draft is responsible for omitting the input
provided the authorization mechanism. It is not the authorization
mechanism itself that is responsible for the omission.
The goal of the appeal is to better ensure information is available
that is required to assess the reputation of the "authenticated origin
identity" as specified by section 4.1. The presence of this
information will not be of harm to recipients, and will better ensure
their safety as well as that of the domain. The issue is only whether
to display or not the results of this header at the MUA after checking
the reputation of its source. In order to perform this check, the
"authenticated origin identity" must be clearly represented in the
trusted headers.
The IESG faces the hard decision of whether they are to act in the
greater interests of better protecting millions of recipients, or
acquiesce to the interests of influential providers acting out of self
interest.
Douglas Otis and Dave Rand
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf