Re: Comments requested on recent appeal to the IESG

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

 




On Feb 23, 2009, at 12:32 AM, Murray S. Kucherawy wrote:

On Sun, 22 Feb 2009 13:11:26 -0800, Doug Otis wrote:
This appeal boils down to "someone might misuse it so don't standardize it." Is there any standard to which someone couldn't have made a similar objection?

The appeal is in regard to offering recipients potentially misleading information where its source is intentionally omitted thus preventing reputation evaluation by the MUA as required by section 4.1.

This assertion, which is the premise behind much of the logic within the appeal and its varied antecedents, is manifestly false. The draft not only does NOT establish that requirement, it goes to some length to suggest doing so is a bad idea.

Review the first sentence of the fourth paragraph of section 4.1.
,---
An MUA SHOULD NOT reveal these results to end users unless the results are accompanied by, at a minimum, some associated reputation data about the authenticated origin identifiers within the message.
'---

Since *authorization* does not *authenticate* a domain as having originated a message, this leaves just the IP address of the SMTP client as a weakly "authenticated origin identifier". The IP address of the SMTP client is the input for Sender-ID or SPF *authorization* mechanisms. Checking the reputation of the "authenticated origin identifier" determines whether this identifier protects the message elements used to establish the *authorization* prior to revealing the *authorization* results.

Appendix D of the draft pertains to the rejection of messages at border MTAs, and to not repeating verification processes that border MTAs should perform. Neither of these functions is being sought by the appeal.

The appeal seeks a means to check the reputation of the "authenticated origin identity" to determine whether it might be safe to reveal results of an *authorization* mechanism. This requirement is clearly stipulated by section 4.1. Again, this is not about whether to block or reject messages or repeating a verification process, this about determining whether it might be safe to reveal authorization results. Checking the authorization protections offered by the IP address of the SMTP client, prior to revealing that an IP address has been authorized, represents an essential element needed to ensure security.

Border MTAs have shown a willingness to make assumptions about authorization, and about the SMTP client's protection of the elements used to obtain the authorization. Unfortunately, when either of these assumptions are incorrect, this allows bad actors a means to obtain credentials that are likely to dupe their victims. With all the uncertainties involved as to whether authorization is intended, or whether authorization elements are protected, limiting reputations to just authorizing domains will create irreconcilable conflicts between sender, receiver, and MUA.

In addition, including the IP address of the SMTP client makes the header less deceptive. Recipients must consider which identifier has been authenticated. It is the *authenticated* IP address of the SMTP client that is being *authorized* by Sender-ID or SPF. Using this IP address to replace the local-part avoids the conditional inclusion of the local-part that is required by section 2.4.3. This section confuses authorization with authentication where even local-part authorization can only be determined after examining internal elements within SPF records. Tracking the *authorization* role of the local- part is not a defined output of either authorization mechanism, nor is it safe to process SPF record local-part macros!

-Doug
_______________________________________________

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]