Re: Comments requested on recent appeal to the IESG

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

 




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

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