Subject: Comments requested on recent appeal to the IESG

From: The IESG <[email-masked]>
Date: Thu, 19 Feb 2009 17:31:23 -0800 (PST)

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

The IESG plans to make a decision in the next few weeks, and solicits
comments on the concerns raised in the appeal.  Please send comments
to the [email-masked] mailing list by 2009-02-28.  Exceptionally,
comments may be sent to [email-masked] instead. In either case,
please retain the Subject line to allow automated sorting.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 19 Feb 2009 18:04:31 -0800

>    http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt

Greetings.

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.

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.

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.

Detailed comments follow:

 > Authentication-Results Header Field Appeal

 > 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.

To the extent that one might construct that need, it can (and should) be a
separate mechanism from the report definition, much as SMTP Auth or Open PGP are
separate from the defintion of IMF (RFC5322).

 > 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".

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.

 > 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.

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.

More generally, they seemed believe that the specification's ability to carry
data on behalf of multiple types of security functions means that information
from the different functions gets mashed together and becomes indistinguishable.
This is the only way I can guess why they think that an SMTP Client
authorization function can be confused with an "email address domain" -- but,
then, I have to guess what they mean by email address domain.  Perhaps they mean
the rfc5322.From field address, but perhaps they mean the rfc5321.mailfrom, or
some other address associated with a message. Again, they provide no specifics
about either of these functions.

 > 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.

 >    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.

Concerning this following portion of the appeal:

 > Table of Contents
 >
 > 1.  Introduction 2.  IPv6, SPF macros, and local-parts 3.  Recommended
 > Modifications 4.  References 4.1.  References - Normative 4.2.  References -
 > Informative Authors' Addresses
 >
 > 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.

 > 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.

 > [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.b

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.

In addition, as a matter of simple vocabulary semantics, the chosen field name
accurately represents the role this carried information plays.

 > 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 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.

 > 2.  IPv6, SPF macros, and local-parts

Linking IPv6 with Auth-Res is creative, but spurious.

 > 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.

 > 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.
Auth-res is an entirely inappropriate venue for such semantics.

 > 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.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Feb 2009 21:32:54 -0500

>This appeal lacks merit on basic points.
+1.  I don't think I could have said it better myself.  

I was involved in the MARID and DKIM working groups and was involved in the 
group that helped put together this draft.  All these points have been made 
before and got not traction in these various venues.

Scott K
Scott K

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Feb 2009 21:00:54 -0800

Just as a matter of observation, there is not and never has been a security requirement to rigidly separate authentication and authorization. Indeed there is no real world deployment in which authentication and authorization are not conflated to some degree.
 
The separation of authentication and authorization is a matter of administrative and operational convenience.
 
It is very rarely the case that every privilege that might potentially be granted to a user is known in advance. Hence the benefit of maintaining a distinction. But in practice the fact that a party holds a valid authentication credential is in itself often (but not always) sufficient to make an authorization decision in low-risk situations.
 
Thus an objection based on the mere risk that such a conflation may occur is not justified as such conflation has occured in every practical security system ever.
 
We do not issue employee authentication badges to non-employees. Thus an employee-authentication badge will inevitably carry de-facto authorization for any action that is permitted to every employee (like open the office door).
 
The Authorization/Authentication model is in fact broken, in a modern system such as SAML you actually have three classes of data with the introduction of attributes.

________________________________

From: [email-masked] on behalf of Scott Kitterman
Sent: Thu 2/19/2009 9:32 PM
To: [email-masked]
Subject: Re: Comments requested on recent appeal to the IESG

Scott K
Scott K

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 20 Feb 2009 09:44:13 -0000

>   http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt

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?

Much of the bad stuff they say about SPF and Sender-ID is correct, but
it'll be equally true whether or not a header reports the results.

I have reviewed the draft and find it to be technically sound.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Feb 2009 10:57:19 -0800 (PST)

On Thu, 19 Feb 2009 17:31:23 -0800 (PST), The IESG wrote:
> [...]

I am the author of the draft under appeal.

To the best of my knowledge, the appeal text is only a slight revision
of issues raised by Mr. Otis on the mailing list where work of producing
the draft was done, and again during that list's last call, and again
during IETF Last Call, and yet again during an additional SECDIR review
requested by the sponsoring Area Director specifically to assess and respond
to his concerns as documented in draft-otis-auth-header-sec-issues-00.

All of the issues Mr. Otis raises have been given substantially more than a
normal amount of consideration, yet they have failed to attract any detectable
consensus.  Disagreement with both his concerns and his proposed remedies is
ample and well-documented.

Indeed, a sizable amount of text was added to the draft during its later
revisions to respond to several of the concerns raised by Mr. Otis, explaining
why the draft adopted the format and guidance it contains today and why his
proposed remedies were not appropriate.

As there are no new issues raised by this appeal, I respectfully request that
the appeal be dismissed.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 20 Feb 2009 15:46:09 -0800

> As there are no new issues raised by this appeal, I respectfully request that

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Feb 2009 14:49:51 -0500

At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01C99318.3582B8D8"
>
>Just as a matter of observation, there is not and never has been a 
>security requirement to rigidly separate authentication and 
>authorization. Indeed there is no real world deployment in which 
>authentication and authorization are not conflated to some degree.

Authentication and authorization (aka access control) are distinct 
security services. Too often they are confused, and the result of 
such confusion is never a great outcome.  I have not read the doc in 
question, but your dismissal of this issue is not persuasive.

>  The separation of authentication and authorization is a matter of 
>administrative and operational convenience.

nonsense. the two are implemented via a wide range of mechanisms, 
many of which are independent of one another. I may use passwords or 
challenge-response mechanisms or PKI technology for authentication, 
and use various identity-based authorization mechanisms with any of 
these means of verifying an identity. Thus there are good technical 
and design reasons to consider the services and mechanisms 
separately, as part of a modular design approach.

>It is very rarely the case that every privilege that might 
>potentially be granted to a user is known in advance. Hence the 
>benefit of maintaining a distinction. But in practice the fact that 
>a party holds a valid authentication credential is in itself often 
>(but not always) sufficient to make an authorization decision in 
>low-risk situations.

True, but the fact that you had to employ several qualifiers in these 
sentences to make them true illustrates the benefits of 
distinguishing between the terms.

>  Thus an objection based on the mere risk that such a conflation may 
>occur is not justified as such conflation has occured in every 
>practical security system ever.

I  don't know if the objection is an important one here, but I do 
think it is important in general.

>We do not issue employee authentication badges to non-employees. 
>Thus an employee-authentication badge will inevitably carry de-facto 
>authorization for any action that is permitted to every employee 
>(like open the office door).

A good example to make my point.  It is typically the case that if 
all employees have ID badges, these badges grant access to most 
buildings/rooms of the employer's facilities. But many other rooms of 
an employer's facilities typically are off limits to all but a few 
employees.

>The Authorization/Authentication model is in fact broken, in a 
>modern system such as SAML you actually have three classes of data 
>with the introduction of attributes.

SAML allows one to make security assertions of all sorts. The fact 
that one can make both authentication and authorization assertions 
using the same construct is distinct from the question of whether 
conflating the two terms is a good idea in general, as you seem to be 
arguing.

Steve

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 20 Feb 2009 19:06:06 -0800

Stephen Kent wrote:
>> Just as a matter of observation, ...
...
>        I have not read the doc in
> question,...

Hey guys.  As someone who is frequently faced with trying to parse out what are 
and are not the commonly held views among the security community, I'm actually 
interested in this type of exchange.

But as you both note, this exchange isn't critical to resolution of the the 
appeal.

For those of who want to see this appeal dispatched as quickly and as painlessly 
as possible, is there a chance that you can continue the exchange under a 
different guise, at a minimum under an entirely independent thread?

d/

-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Sat, 21 Feb 2009 01:23:06 -0800

>ample and well-documented.

As a participant to the discussions that lead to 
draft-kucherawy-sender-auth-header-20, I can confirm that the issues 
raised by Mr Otis were discussed on the mailing list - see

http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000390.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000398.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000409.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000504.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000507.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000549.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000550.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000552.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000558.html

During the IESG evaluation, a secdir review of 
draft-otis-auth-sender-sec-issues-00, which raises alleged security 
issues was requested.

The appeal mentions that:

   'In the case of Sender-ID or SPF, the deceptive nature of this header
    could have been remedied by including the "authenticated" IP address
    of the SMTP client, in addition to the authorizing domain.'

That is at odds with the second paragraph of the appeal where the 
authors of the appeal point to the downside in the era of carrier 
grade  NATs, virtual servers, aggregated services, and other 
techniques that overload the IP address.

The appeal states that the its goal is to ensure adequate information 
is available when annotating email.  The last paragraph mentions that 
an MTA adding this header field SHOULD NOT include any data which has 
not  been authenticated by the method(s) being applied.  It then 
proposes an exception for an Authorizing domain only when it 
accompanies the authenticated IP address of the SMTP client.

Assigning a negative rating to an affected SMTP client IP addresses 
mitigates the security breach problem while completely blocking all 
messages from the domain and other domains hosted in a virtual server 
environment.  Furthermore, basing MUA annotations on the rating of an 
IP address is questionable as messages are not always retrieved 
immediately after delivery.

The appeal gets into a discussion about IPv6, SPF macros, and 
local-parts.  draft-kucherawy-sender-auth-header-20 defines a header 
to capture email verification results.  It is not about the internals of SPF.

There is a recommended modification that the "pvalue" reported along 
with results for these mechanisms SHOULD NOT include the local-part.

Quoting the draft under appeal, the value:

   For Sender ID: value of header field used by PRA after removing comments
     and parts not authenticated

   For SPF: envelope sender after removing parts not authenticated

That cannot be interpreted as the local-part should be included.

As for the confusion about authorization with authentication in 
section 1.5.2 of draft-kucherawy-sender-auth-header-20, there is a 
reference to BCP 72 and it quotes Section 4.4 which describes 
authorization and authentication.  Authentication simply identifies a 
party, authorization defines whether they can perform a certain 
action.  Authorization necessarily relies on authentication, but 
authentication alone does not imply authorization.

draft-kucherawy-sender-auth-header-20 describes SPF and Sender ID as 
authorization mechanisms in that they express a result that shows 
whether or not the ADMD that apparently sent the message has 
explicitly authorized the connecting SMTP client to relay messages on 
its behalf but do not actually validate any property of the message 
itself.  The author of the draft mentions that rather than create a 
separate header field for each class of solution, this proposal 
groups them both into a single header field.

Regards,
-sm

---

From: Stephen Kent <[email-masked]>
Date: Sat, 21 Feb 2009 11:12:38 -0500

At 7:06 PM -0800 2/20/09, Dave CROCKER wrote:
>Hey guys.  As someone who is frequently faced with trying to parse 
>out what are and are not the commonly held views among the security 
>community, I'm actually interested in this type of exchange.
>
>But as you both note, this exchange isn't critical to resolution of 
>the the appeal.
>
>For those of who want to see this appeal dispatched as quickly and 
>as painlessly as possible, is there a chance that you can continue 
>the exchange under a different guise, at a minimum under an entirely 
>independent thread?
>
>d/

Dave,

My belief is that IF the doc conflates authentication and 
authorization, then some intelligent editing probably can fix that 
problem quickly.  Since, as you and other have noted, the WG is n 
board with this doc, the issue Phil raised, and to which I responded, 
ought not affect approval of the document.

Steve

---

From: Douglas Otis <[email-masked]>
Date: Sat, 21 Feb 2009 11:53:01 -0800

On Feb 19, 2009, at 6:04 PM, Dave CROCKER wrote:
> 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.
>
> 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.

>> 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  

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.

>> assessments which section 4.1 indicates should be made prior to  
>> results being revealed.
>

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.

>> 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.

>> 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.
'---

> 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.
>
> authentication report, if it has not been authenticated.  All that  
> that encourages is authentication. Extrapolating that requirement  
> into encouraging

It is rather naive to expect senders will not seek greater prominence  
that might be achieved with a greater amount of annotation.

>> 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.
>

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

---

From: Doug Otis <[email-masked]>
Date: Sun, 22 Feb 2009 13:11:26 -0800

On Feb 20, 2009, at 1:44 AM, John Levine wrote:

> 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.

> Much of the bad stuff they say about SPF and Sender-ID is correct,  
> but it'll be equally true whether or not a header reports the results.
>

Dave Crocker made a point about not necessitating the examination of a  
mechanism's internals when objecting to the inclusion of the IP  
address of the SMTP client.  Dave Crocker was confused since this same  
input is also provided to an infrequently used "iprev" where this  
input is captured by the Authentication-Results header.  However  
section 2.4.3.  "SPF and Sender-ID Results" of the draft stipulates  
conditional inclusion of a local-part, but the local-part's role is  
not defined by the output of the "spf" mechanism.  The "senderid"  
mechanism stipulates the local-part plays no role.  Clearly, such  
source omission and conditional inclusion represents a technical error.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Feb 2009 00:32:13 -0800 (PST)

> 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.

---

From: Doug Otis <[email-masked]>
Date: Mon, 23 Feb 2009 11:20:58 -0800

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

>> 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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 24 Feb 2009 09:29:38 +0100

Doug Otis wrote:
> 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.

Hm... the IP address is authenticated by the TCP session. Next, the 
self-styled domain is looked up checking for an authorization for the 
given IP address. Up to DNS reliability, a positive result proves the 
validity of the domain name, in the sense that the domain admins have 
stated that messages originating from the given IP may righteously 
claim to originate from that domain. Why wouldn't that make up an 
authentication of the given domain name?

>  Checking the reputation of the "authenticated origin 

It is not clear to me what checking would the MUA do in practice.

> the local-part that is required by section 2.4.3.

I doubt that displaying "[email-masked]" will make the 
recipient safer. Users who know what to do with an IP address are also 
able to look at the Received or Received-SPF headers directly. MUAs 
tend to conceal even true email addresses from end users, for some reason.

>  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!

A domain interested in verifying the local part might combine the 
"exist" mechanism with a purposely built DNS zone. What's wrong with 
processing local macros? I agree that if no local macro has been 
processed one can safely consider the local part as not having been 
validated. However, the converse statement does not hold. I'd say that 
only MTAs whose SPF-checking implementation traces the use of local 
macros may conclude that the local part was not specifically checked, 
and thence conceal it.

Another not commonly implemented possibility is that a site 
dynamically updates its DNS records according to DHCP leases, and 
synchronizes the SPF record TTL with the lease duration. How would a 
MUA cope with that if, say, it downloads the message on the next day?

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Feb 2009 11:40:18 -0800

>> client as a weakly "authenticated origin identifier".  The IP  
>> address of the SMTP client is the input for Sender-ID or SPF  
>> *authorization* mechanisms.
>
> Hm... the IP address is authenticated by the TCP session.

Yes, weakly authenticated.

> Next, the self-styled domain is looked up checking for an  
> authorization for the given IP address.

Such as example.com references an SPF record that produce the following:

...
--- or ---

header.from=example.com
...
From: The Club<[email-masked]>

> Up to DNS reliability, a positive result proves the validity of the  
> domain name, in the sense that the domain admins have stated that  
> messages originating from the given IP may righteously claim to  
> originate from that domain.

Positive authorization results will not safely indicate whether a  
domain originated a message (and will not represent authentication)  
when any of the following might be true:

1) Publishing the SPF record was intended to ensure delivery or to  
minimize backscatter, but was not to ensure source authenticity.   
(Ensuring delivery is a common reason for publishing SPF records.)

2) The authorization reference (such as Mail From or From as above)  
was not restricted to just the domain's users. (It is a common  
practice not to impose restrictions on the use of the Mail From or the  
PRA.)

3) Separate SMTP clients share the same IP addresses.  (Unfortunately  
this is also a common practice.  Brazil, Poland, and other places have  
many ISPs that expect hundreds or thousands of customers to run  
outbound SMTP services that NAT to a single or small number of IP  
addresses.  It is also common for VPS services to run servers out of  
common IP addresses.)

4) Authorization results that are based upon a virtual record when no  
SPF record is found.  (Injecting SPF mx/24 record mechanisms whenever  
no SPF is discovered is also a common practice.)

5) The SPF Authorization is not intended to be referenced from a PRA  
message element. (There may be uncertainty whether a PRA is a valid  
reference due to conflicts between RFC 4406 and RFC 4408.)

6) A domain that employs outside email providers to handle inbound  
email, but then inadvertently includes an MX mechanism where the  
inbound provider also offers outbound services to thousands of domains  
from the same IP address space.  (This now will likely be found to be  
a common mistake.)

> Why wouldn't that make up an authentication of the given domain name?

Any common situation from 1 - 6 eliminates any reasonable assurance  
that a domain originated the message.  It can only be said that a  
domain *authorized* the SMTP client.  Assigning reputations to a  
domain on that basis is not easily reconciled, nor will marking the  
domain "unsuitable for annotation" offer timely protection for other  
domains that are also sharing the SMTP client IP address.  This is not  
about blocking messages, this is about annotating messages.

>> 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.
>

When annotating a domain as having originated a message is based upon  
SMTP client authorization, the reputation of SMTP clients is  
critically important.  As enumerated by the list 1 - 6, not all IP  
addresses used by SMTP clients will restrict a domain's use to just  
their users.

>> 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.
>
> recipient safer.

The alternative might be "[email-masked]" is used with a message  
asking you to complete your W2 form at a specific web-site.    
Unfortunately, the MUA is unable to check whether 192.0.2.3 has a  
recent history of spoofing domains.  Employees of example.com may be  
unaware of the limitations imposed by their outsourced email service,  
or may have created records intended to help ensure message delivery.  
Bad actors can now leverage any "righteous" assumptions that border  
MTAs might make to produce extremely convincing socially engineered  
attacks.  See items 1- 6.  These attacks are made easier whenever  
*authorization* is erroneously elevated into being considered  
*authentication* without adequate safeguards being provided.   
Safeguards based only upon a domain will not isolate the services  
culpable for domain spoofing and will inhibit an effective response to  
SMTP client exploits.

> Users who know what to do with an IP address are also able to look  
> at the Received or Received-SPF headers directly. MUAs tend to  
> conceal even true email addresses from end users, for some reason.

When Authentication-Results headers cause a consolidation of added  
headers, SMTP client IP address may no longer be available when  
processing *authorization* mechanisms.  The Authentication-Results  
header can occur at subsequent MTAs which does not help identify which  
Received header can be trusted.  In addition, not all Received headers  
include the IP address of the SMTP client.  Inclusion of the SMTP  
client IP address is being sought is to better determine whether it  
might be safe to reveal authorization results.

>> 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!
>
> "exist" mechanism with a purposely built DNS zone.

The SPF exist() function must combine local-parts with the IP  
addresses of the SMTP clients.  Using the macro "exists:%{ir}.%{l 
+_}._spf.%{d}" will authorize a message that references an A record at  
"_spf.<domain>"  with labels that comprise reverse octets of the SMTP  
client IP address followed by local-part characters, where '+' and '_'  
characters are replaced by periods.  While the macro capability of SPF  
offers flexibility, it also provides bad actors the ability to define  
any new sequence of 10 DNS transactions constructed from a single  
cached SPF record.

> What's wrong with processing local macros?

During a spam campaign, by varying local-parts (which is already  
normally done), any macro driven transactions may just expend the  
recipient's DNS resources, and target any otherwise innocent domain.   
This provides an otherwise free method to attack while spamming.   Any  
method to combine the user namespace with SMTP client authorization is  
likely to require a substantial amount of recipient generated DNS  
traffic.

> I agree that if no local macro has been processed one can safely  
> consider the local part as not having been validated. However, the  
> converse statement does not hold.

A) It might be painful for innocent third-parties when recipients  
process local-part macros.

B) There is no output specified by the SPF mechanism to indicate what  
portion of a local-part, if any, plays a role in the authorization.

> I'd say that only MTAs whose SPF-checking implementation traces the  
> use of local macros may conclude that the local part was not  
> specifically checked, and thence conceal it.

In converse, conditional annotations based upon the use of local-part  
macros will encourage the use of this dangerous mechanism.

> synchronizes the SPF record TTL with the lease duration.

Agreed.  This is not common.

> How would a MUA cope with that if, say, it downloads the message on  
> the next day?

If such dynamic use of SPF were to become popular, a reputation  
service could return A records where the least significant bits encode  
the number of second since a problem was noted.  It seems unlikely  
there will be a demand for solving this issue, but it would not be  
impossible.  Our service already tracks hundreds of millions of IP  
addresses where activity is already measured in this manner.

It is fairly common to accrue reputations over a range IP addresses.   
When this range of IP addresses does not spoof domains, revealing  
results should be safe.  It is also fairly common for ISPs to  
transparently intercept port 25 traffic or to force the sharing of  
common IP addresses.   In this case, it is _never_ safe to assume that  
an authorized SMTP client provides even a modicum of proof that a  
particular domain originated the message.

Only the IP address of the SMTP client offers a practical means to  
track IP address sharing.  Attempting to track IP address sharing by  
domain will be fairly impractical since tens of thousands of domains  
might authorize the same IP addresses, but SPF does not offer a  
reverse namespace.  Marking a domain as "unsuitable for annotation"  
that never issued abuse is likely to incur expensive support calls and  
involve the SMTP client providers anyway.  Not including the SMTP IP  
address will produce more victims for confidence artists and make  
defending an authorization mechanism more expensive.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 26 Feb 2009 19:47:51 +0100

Douglas Otis wrote:
> 
> Received: by SMTP id j2cs23447wfe;
>      Tue, 24 Feb 2009 09:51:01 -0800 (PST)
> Return-Path: <[email-masked]>
> Authentication-Results: trusted-isp.com; spf=pass smtp.mail=example.com
> ...
> --- or ---
> 
> Received: by SMTP id j2cs23447wfe;
>      Tue, 24 Feb 2009 09:51:01 -0800 (PST)
> Return-Path: <[email-masked]> (SMTP Mail From parameter)
> Authentication-Results: trusted-isp.com; senderid=pass 
> header.from=example.com
> ...
> Positive authorization results will not safely indicate whether a domain 
> originated a message (and will not represent authentication) when any of 
> the following might be true:
> 

SPF records with "+all" is like people hand signing blank sheets, they 
shouldn't be surprised when someone abuses of their slapdash attitude. 
However, recipients can still attach such annotation about the domain 
attitude to the domain name.

> 2) The authorization reference (such as Mail From or From as above) was 
> not restricted to just the domain's users. (It is a common practice not 
> to impose restrictions on the use of the Mail From or the PRA.)

I'm not sure if you mean the effect of the SPF record. (In that case, 
the previous comment holds.)

> many ISPs that expect hundreds or thousands of customers to run outbound 
> SMTP services that NAT to a single or small number of IP addresses.  It 
> is also common for VPS services to run servers out of common IP addresses.)

The domain that operates the NAT is responsible for letting their 
users connect to port 25. Operating through a NAT may disrupt an inner 
site's activity, if some of its co-NAT sites behave badly. Again, 
recipients can mark this weak authentication characteristic by domain 
name.

> SPF record is found.  (Injecting SPF mx/24 record mechanisms whenever no 
> SPF is discovered is also a common practice.)

That's totally bogus. I may accept a bug in my ISP's SPF checking 
software, but deliberately falsifying the data requires that 
"trusted-isp.com" be removed from my set of trustees.

> reference due to conflicts between RFC 4406 and RFC 4408.)

True. Let's hope someone rewrites the relevant RFC...

> email, but then inadvertently includes an MX mechanism where the inbound 
> provider also offers outbound services to thousands of domains from the 
> same IP address space.  (This now will likely be found to be a common 
> mistake.)

Even if that's a common mistake, I would annotate them as a marginally 
trusted domain. Obviously, their policy doesn't provide for checking 
their own settings.

> Any common situation from 1 - 6 eliminates any reasonable assurance that 
> a domain originated the message.

I would regard the message as being originated by "example.com" and 
then check if I have any annotation about that domain name.

>  It can only be said that a domain *authorized* the SMTP client.

Yes, the client is authorized to say it sends on behalf of that 
domain: it is a user of that domain by definition.

>  Assigning reputations to a domain on that 
> basis is not easily reconciled, nor will marking the domain "unsuitable 
> for annotation" offer timely protection for other domains that are also 
> sharing the SMTP client IP address.  This is not about blocking 
> messages, this is about annotating messages.

If I understand you correctly, you're saying that the domain itself 
cannot be considered guilty of writing a specific message, but only of 
not having enforced enough protective measures. Perhaps, that is 
correct. However, a domain can never "write a message" personally, 
because it is an abstract entity. It can only authorize other entities 
to write on its behalf. That's why annotating its attitude at issuing 
authorizations is important.

BTW, I'd like "marginally trustworthy" better then "unsuitable for 
annotation". The fact is that the recipient cannot trust it. Sharing a 
NAT with criminals might not be the domain admins' fault, but the fact 
remains that the domain cannot be trusted.

> SMTP client authorization, the reputation of SMTP clients is critically 
> important.  As enumerated by the list 1 - 6, not all IP addresses used 
> by SMTP clients will restrict a domain's use to just their users.

By "just their users" you mean "the users authorized by the domain"? 
In facts, a domain could publish the full list of its authorized 
users, then, e.g. because of some of situations 1-6, someone who is 
not on that list manages to write a message that gets, say, an SPF 
"pass" and the consequent authentication record. Then, either the full 
list of authorized users is false, or the domain is not technically 
able to issue correct authorizations. In both cases the domain is not 
trustworthy.

> The alternative might be "[email-masked]" is used with a message asking 
> you to complete your W2 form at a specific web-site.   Unfortunately, 
> the MUA is unable to check whether 192.0.2.3 has a recent history of 
> spoofing domains.  Employees of example.com may be unaware of the 
> limitations imposed by their outsourced email service, or may have 
> created records intended to help ensure message delivery. Bad actors can 
> now leverage any "righteous" assumptions that border MTAs might make to 
> produce extremely convincing socially engineered attacks.  See items 1- 
> 6.  These attacks are made easier whenever *authorization* is 
> erroneously elevated into being considered *authentication* without 
> adequate safeguards being provided.  Safeguards based only upon a domain 
> will not isolate the services culpable for domain spoofing and will 
> inhibit an effective response to SMTP client exploits.

With the possible exception of some guys of the IT department, I think 
no employee of example.com can tell if 192.0.2.3 is or is not the IP 
address of their ESP. A decent ESP should ensure that spoofed messages 
claiming to originate from within the company itself are rejected 
right at the SMTP level, e.g. restricting mailers to use authenticated 
SMTP with strong encryption. Failing that, all what a MUA can do is to 
mark messages originating from example.com as not trustworthy, given 
the annotations that can be done on that domain name.

As for tracing spoofing attacks, a MUA sees too little traffic to be 
able to do such activity. Attackers can have such a light footprint 
that even DNSBLs with myriads of honeypots might be unable to trace 
them. At any rate, if that is your concern, I wonder why you didn't 
propose to include the results of looking up some DNSBLs rather than 
pass the IP address along in that header. Capturing such information 
may obviously be useful for attributing more or less reputation to a 
given message...

I know that sudden bursts of spam from otherwise silent IP addresses 
defeat the effectiveness of transfer-time DNSBL lookups, thus it may 
make some sense to schedule further lookups of the same IP at well 
balanced time intervals after a message acceptance, but I don't think 
that a manually launched MUA could cope with such precise timing 
requirements.

> include the IP address of the SMTP client.

That seems to be questioning which MTAs' headers one trusts. Of 
course, it is the boundary MTA who can produce interesting results. 
Thus, recipients are better off choosing one that they can trust.

> The SPF exist() function must combine local-parts with the IP addresses 
> of the SMTP clients.  Using the macro "exists:%{ir}.%{l+_}._spf.%{d}" 
> will authorize a message that references an A record at "_spf.<domain>"  
> with labels that comprise reverse octets of the SMTP client IP address 
> followed by local-part characters, where '+' and '_' characters are 
> replaced by periods.  While the macro capability of SPF offers 
> flexibility, it also provides bad actors the ability to define any new 
> sequence of 10 DNS transactions constructed from a single cached SPF 
> record.

Yup, that's how a domain can be picky on the authorizations it issues 
even without forcing its users to use a fixed MSA.

> likely to require a substantial amount of recipient generated DNS traffic.

The limit on the number of lookups should be low enough to dim DoS 
attacks.

> process local-part macros.

That's true. Perhaps, sensible implementations should check that the 
local part is not the terminating part of the name to be queried. In 
any case, sites that publish records intended to play DoS attacks 
should be considered responsible of what they do. (MX records lend 
themselves to similar exploits.)

> portion of a local-part, if any, plays a role in the authorization.

True. I interpret it as leaving it up to the site admins to decide 
their policy. The net result should be that any local part from an 
authorized sender is reliable as much as the authorizing domain is 
trustworthy.

> macros will encourage the use of this dangerous mechanism.

Agreed, not because of the danger (that should be dealt with by other 
means), but because it would be silly to impose mentioning a local 
part macro for that sole purpose. Possibly, a domain already has an 
MSA that rigorously checks any local part as their only authorized 
sender address, but it should include a local macro (perhaps in the 
explanation) if it wants its local parts to be validated...?

> If such dynamic use of SPF were to become popular, a reputation service 
> could return A records where the least significant bits encode the 
> number of second since a problem was noted.  It seems unlikely there 
> will be a demand for solving this issue, but it would not be 
> Only the IP address of the SMTP client offers a practical means to track 
> IP address sharing.  Attempting to track IP address sharing by domain 
> will be fairly impractical since tens of thousands of domains might 
> authorize the same IP addresses, but SPF does not offer a reverse 
> namespace.  Marking a domain as "unsuitable for annotation" that never 
> issued abuse is likely to incur expensive support calls and involve the 
> SMTP client providers anyway.  Not including the SMTP IP address will 
> produce more victims for confidence artists and make defending an 
> authorization mechanism more expensive.

Those are all good ideas for reckoning reputation. However, as you 
point out, they are meant to be rolled out as services, not tasks that 
each MUA carries out on its own. Such services may run on downstream 
MTAs who need more coordination with the border MTAs, or at third 
parties' sites who need to know the IP address of the SMTP client as a 
parameter. As far as I can tell from having read a fair amount of this 
topic, in neither case the IP address is considered an authentication 
result: it is the parameter for obtaining an authentication result. 
Thence, my wonder about why that result --not its parameter-- doesn't 
have a Method, a definition, ptypes, and properties as provided by the 
Email Authentication Result Name Registry, in order to be included 
into the Authentication-Results header, is the same as for the DNSBL 
lookup I mentioned above.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Feb 2009 11:36:10 -0800

I find these arguments to be unpersuasive and somewhat offensive.
 
There is no way for any machine to ever know where one ends and the other begins. Ergo it will be possible for someone to object to any protocol on the grounds that someone might conflate Authorization and Authentication. This is inevitable because there will be occasions where the intended authorization policy for a resource is to allow through everything that is authenticated.

From: Stephen Kent [mailto:[email-masked]]
Sent: Fri 2/20/2009 2:49 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]
Subject: RE: Comments requested on recent appeal to the IESG

Authentication and authorization (aka access control) are distinct security services. Too often they are confused, and the result of such confusion is never a great outcome.  I have not read the doc in question, but your dismissal of this issue is not persuasive.

nonsense. the two are implemented via a wide range of mechanisms, many of which are independent of one another. I may use passwords or challenge-response mechanisms or PKI technology for authentication, and use various identity-based authorization mechanisms with any of these means of verifying an identity. Thus there are good technical and design reasons to consider the services and mechanisms separately, as part of a modular design approach.

True, but the fact that you had to employ several qualifiers in these sentences to make them true illustrates the benefits of distinguishing between the terms.

I  don't know if the objection is an important one here, but I do think it is important in general.

A good example to make my point.  It is typically the case that if all employees have ID badges, these badges grant access to most buildings/rooms of the employer's facilities. But many other rooms of an employer's facilities typically are off limits to all but a few employees.

SAML allows one to make security assertions of all sorts. The fact that one can make both authentication and authorization assertions using the same construct is distinct from the question of whether conflating the two terms is a good idea in general, as you seem to be arguing.

Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Feb 2009 17:33:23 -0800

On Feb 26, 2009, at 10:47 AM, Alessandro Vesely wrote:

> Douglas Otis wrote:
>>
>> 3) Separate SMTP clients share the same IP addresses.   
>> (Unfortunately this is also a common practice.  Brazil, Poland, and  
>> other places have many ISPs that expect hundreds or thousands of  
>> customers to run outbound SMTP services that NAT to a single or  
>> small number of IP addresses.  It is also common for VPS services  
>> to run servers out of common IP addresses.)
>
> users connect to port 25. Operating through a NAT may disrupt an  
> inner site's activity, if some of its co-NAT sites behave badly.  
> Again, recipients can mark this weak authentication characteristic  
> by domain name.

Alessandro,

Tens of thousands of domains might use the same NATed addresses  
offered by a network carrier.  For authorization mechanisms, if the  
SMTP client IP address was included within the Authentication-Results  
header, then messages emerging from known NATed addresses could be  
easily identified, and appropriately they would not receive  
annotations as having originated from an authorizing domain.  The  
proactive protections afforded by inclusion of the SMTP client IP  
address would be substantial.

There are hundreds of thousands of legitimate SMTP clients in  
comparison to hundreds of millions of domains.  This sizable  
difference makes SMTP client based annotation assessment a thousand of  
times more comprehensive.  It is already very difficult to detect  
spear phishing events.  Basing assessments only upon events evidenced  
by the domain, rather than by the SMTP client IP address, means this  
insidious activity is more likely to go on unabated.

>> 4) Authorization results that are based upon a virtual record when  
>> no SPF record is found.  (Injecting SPF mx/24 record mechanisms  
>> whenever no SPF is discovered is also a common practice.)
>

Customers of such providers will still desire their email to be  
annotated.  They will be asked to enter the name of their provider  
into the MUA while being unaware of any underlying SPF record  
guesswork.  Allowing the MUA a means to check the status of the SMTP  
client reduces risks created by authorization guesswork or a  
provider's acceptance requirements.  Judging whether to annotate is a  
much different decision from deciding whether to accept a message.
...
> domain: it is a user of that domain by definition.

This statement is not correct.  This is why it is so wrong to confuse  
*authorization* with *authentication*.

A package delivered by Fred bearing Sam's return address where Sam  
references Fred as being *authorized* does not represent an assurance  
that the package is really from Sam.  Only when Fred has a reputation  
of always checking sender identities against return addresses can  
there be any assurance that the return address is valid.  In addition,  
an authorization of Fred by Sam should not be considered a guarantee  
that Fred always checks sender identities against the return  
addresses.  An authorization only means packages delivered by  
unauthorized carriers should be considered suspect.  This philosophy  
is often the basis for publishing SPF records when dealing with back- 
scatter.  The reputation most relevant as to whether a return address  
might be valid is that of the carrier Fred.
...
>> recent history of spoofing domains.  Employees of example.com may  
>> be unaware of the limitations imposed by their outsourced email  
>> service, or may have created records intended to help ensure  
>> message delivery. Bad actors can now leverage any "righteous"  
>> assumptions that border MTAs might make to produce extremely  
>> convincing socially engineered attacks.  See items 1- 6.  These  
>> attacks are made easier whenever *authorization* is erroneously  
>> elevated into being considered *authentication* without adequate  
>> safeguards being provided.  Safeguards based only upon a domain  
> With the possible exception of some guys of the IT department, I  
> think no employee of example.com can tell if 192.0.2.3 is or is not  
> the IP address of their ESP.

Per the draft, the MUA is expected to check the reputation of the  
"authenticated origin identity" (this would be the SMTP client IP  
address).  When this address represents that of a NATed IP address,  
the message should not be annotated as being from the authorizing  
domain.  This has nothing to do with the reputation of the domain,  
where look-alike attacks should be blocked by the border MTA anyway.

> A decent ESP should ensure that spoofed messages claiming to  
> originate from within the company itself are rejected right at the  
> SMTP level, e.g. restricting mailers to use authenticated SMTP with  
> strong encryption. Failing that, all what a MUA can do is to mark  
> messages originating from example.com as not trustworthy, given the  
> annotations that can be done on that domain name.

ESP are sensitive to complaints from customers about not receiving  
their messages and may base acceptance upon the SMTP client being  
authorized.   In addition, an authorized SMTP client does not mean  
other domains do not use the same IP address.

> able to do such activity.

It is reasonable to expect the MUA will check the reputation of a few  
hundred thousand IP addresses prior to applying annotations.  There  
are techniques that dramatically reduce the size of this list.  The  
alternative requires much less effective and indirect checks of many  
million authorizing domain names.

>> header can occur at subsequent MTAs which does not help identify  
>> which Received header can be trusted.  In addition, not all  
>> Received headers include the IP address of the SMTP client.
>

Agreed.  But effective protection still requires the border MTAs to  
capture the IP address of the SMTP client.

>> recipient's DNS resources, and target any otherwise innocent  
>> domain.  This provides an otherwise free method to attack while  
>> spamming.   Any method to combine the user namespace with SMTP  
>> client authorization is likely to require a substantial amount of  
>> recipient generated DNS traffic.
>

The limit of even 10 DNS transactions (without going into how this  
might be extended) still represents an attack that does not consume  
_any_ additional resources of the attacker.

> themselves to similar exploits.)

SPF local-parts can also reference MX records and MX record targets  
for additional amplification.  Bad actors also often publish SPF  
records from compromised hosts, where the force of the attack is  
generated by their recipient's DNS resolvers.

>> B) There is no output specified by the SPF mechanism to indicate  
>> what portion of a local-part, if any, plays a role in the  
>> authorization.
>

Agreed.  Why bother to check a local-part, especially when these  
checks might prove painful to innocent third-parties?
...
>> track IP address sharing.  Attempting to track IP address sharing  
>> by domain will be fairly impractical since tens of thousands of  
>> domains might authorize the same IP addresses, but SPF does not  
>> offer a reverse namespace.  Marking a domain as "unsuitable for  
>> annotation" that never issued abuse is likely to incur expensive  
>> support calls and involve the SMTP client providers anyway.  Not  
>> including the SMTP IP address will produce more victims for  
>> confidence artists and make defending an authorization mechanism  
>> more expensive.
>
> point out, they are meant to be rolled out as services, not tasks  
> that each MUA carries out on its own.

The draft clearly indicates that the MUA is obligated to check the  
reputation of the "authenticated origin identity" prior to making  
annotations.

> Such services may run on downstream MTAs who need more coordination  
> with the border MTAs, or at third parties' sites who need to know  
> the IP address of the SMTP client as a parameter. As far as I can  
> tell from having read a fair amount of this topic, in neither case  
> the IP address is considered an authentication result: it is the  
> parameter for obtaining an authentication result.

Results obtained after inputing the *authenticated IP address* (by way  
of TCP interaction) of the SMTP client into mechanisms, such as SPF or  
Sender-ID, will be whether or not the SMTP client has been  
*authorized*.  Only when this SMTP client has a reputation of ensuring  
the Mail From or PRA originates from the user of that domain (perhaps  
with click-through validation associated with the access account),  
would it be safe to annotate a message as originating from the  
*authorizing* domain.  Attempting to indirectly assess SMTP clients  
based upon the authorizing domain makes the assessment orders of  
magnitude less effective and more expensive.

It seems rather obvious why the ESP community wishes to avoid having  
their SMTP client behavior directly assessed.  Unfortunately, holding  
authorizing domains accountable for the actions of the SMTP clients  
they authorize will fail at providing comprehensive protections.   
Misdirected assessment will thwart practical efforts aimed at curbing  
abuse.  Again, this header is about what results are safe to annotate.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 Feb 2009 10:12:18 +0100

Hi,

Douglas Otis wrote:
> There are hundreds of thousands of legitimate SMTP clients in comparison 
> to hundreds of millions of domains.

My understanding is that recipients are only interested in a few 
domain names: their company, their banks, their customers, their 
providers, and the like. While they are probably interested in knowing 
about such site reputations, they don't want to know how often those 
domains' servers change their network settings. Good domain names last 
longer than their IPs.

>> deliberately falsifying the data requires that 
> annotated.

The consistency of requiring perfect reputation of happy-fraud.com is 
questionable. If that's my bank, I should probably think about changing.

> that the package is really from Sam.  Only when Fred has a reputation of 
> always checking sender identities against return addresses can there be 
> any assurance that the return address is valid.

Trusting the return address is only relevant at the transport level, 
MUAs should not provide means to issue bounces. Besides, IMHO, it is 
Sam's reputation that the recipient should be interested in, not 
Fred's. We apparently differ slightly on this subject, but I'd defer 
it, as it is not the most relevant point.

[...]

> hundred thousand IP addresses prior to applying annotations.

Here is where I don't follow you. I, for one, don't have a few hundred 
thousand messages in my mailbox. In addition most of the messages I 
have come from a minority of IP addresses.

>  There are 
> techniques that dramatically reduce the size of this list.  The 

I must understand you're not talking about a process running on the 
MUA, correct?

[...]

> The limit of even 10 DNS transactions (without going into how this might 
> be extended) still represents an attack that does not consume _any_ 
> additional resources of the attacker.

Consuming the attacker's resources is not relevant since they can 
outsource them for free.

> Agreed.  Why bother to check a local-part, especially when these checks 
> might prove painful to innocent third-parties?

(I tend to appreciate the concealment of local parts as a means to 
save horizontal space on the MUA's window...)

> with click-through validation associated with the access account), would 
> it be safe to annotate a message as originating from the *authorizing* 
> domain.  Attempting to indirectly assess SMTP clients based upon the 
> authorizing domain makes the assessment orders of magnitude less 
> effective and more expensive.

I may agree on that even if you didn't specify what techniques would 
be used. However, it seems that, even using those optimizations, the 
implied volume of data is not what a typical MUA has in its mailboxes. 
Thus, it has to rely on an external service. I ask again the same 
question: what is the result that such external service delivers?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Feb 2009 17:45:16 -0800

On Feb 27, 2009, at 1:12 AM, Alessandro Vesely wrote:
>> comparison to hundreds of millions of domains.
>
> providers, and the like. While they are probably interested in  
> knowing about such site reputations, they don't want to know how  
> often those domains' servers change their network settings. Good  
> domain names last longer than their IPs.

Alessandro,

The recommended change does not eliminate the presence of the  
authorizing domain in the authentication-results header, but  
supplements it with that of the SMTP client IP address.  The SPF/ 
Sender-ID mechanism might be intended to only modify the DSN handling  
of messages not from authorized SMTP clients.  Although both RFC 4406  
and RFC 4408 make non-normative comments about what might be deduced  
from an authorizing domain's reputation in respect the validity of  
email-addresses, there is no mandate that ensures an assumption of  
validity.  Some incorrectly expect a domain that has authorized SMTP  
clients, will have only authorized SMTP clients that enforce the  
exclusive use of their domain within either the PRA or Mail From.

Assessing the reputations of SMTP clients indirectly by the  
authorizing domains significantly limits the protections that might be  
achieved whenever domain spoofing is detected.  Targeted phishing is  
already difficult to detect, where many attacks now leverage  
information from social networking sites to determine which domains  
are known by the victims.  While the SMTP client authorized by some  
domains change over time, the protection of the domain within either  
the PRA or Mail From is still a function of the SMTP client, and is  
not directly that of the many many more authorizing domains.

>>> deliberately falsifying the data requires that "trusted-isp.com"  
>>> be removed from my set of trustees.
> The consistency of requiring perfect reputation of happy-fraud.com  
> is questionable. If that's my bank, I should probably think about  
> changing.

This misinterprets the concern.  ESPs optimize profits by reducing  
their support calls.  To do this, they might reduce erroneous  
rejections by tweaking SPF to make guesses.  As such, it is not safe  
to assume that because the ESP accepted a message from an authorized  
SMTP client, that:

   A) the SMTP client was actually authorized, and

   B) that this authorization verifies an authorizing domain emitted  
the message.

The safety of an assumption about an authorizing domain originating a  
message depends upon the reputation of the SMTP client for its  
protection of the PRA and Mail From.  Unfortunately, identifiers for  
the SMTP client have been omitted.  It appears ESPs have agreed not  
hold SMTP clients accountable to reduce ESP support calls.  Having  
some of their customer's domains affected by a security breach is  
preferred over all customer's domains being affected (even when it  
would be appropriate for all domains).

>> references Fred as being *authorized* does not represent an  
>> assurance that the package is really from Sam.  Only when Fred has  
>> a reputation of always checking sender identities against return  
>> addresses can there be any assurance that the return address is  
>> valid.
>
> MUAs should not provide means to issue bounces.

Having the Authentication-Results header include the IP address of the  
SMTP client provides a means to better determine what is safe to  
reveal to the recipient.

> Besides, IMHO, it is Sam's reputation that the recipient should be  
> interested in, not Fred's. We apparently differ slightly on this  
> subject, but I'd defer it, as it is not the most relevant point.

Holding Sam accountable for an SMTP client run by Fred assumes Sam has  
established agreements with Fred stipulating PRA or MAIL FROM  
exclusivity.  Will omission of the SMTP client identifiers morally  
obligate Sam to establish exclusivity service agreements?  Such  
agreements would not be a prerequisite when Fred is held accountable,  
but might be seen as revenue stream by ESPs.  In addition, when Fred's  
security is breached, the PRA or MAIL FROM for any domain delivered by  
Fred should not be trusted until Fred's breach has been mitigated.   
Not being able to determine whether a message was delivered by Fred  
makes comprehensive annotation protections impossible.

When Fred delivers email for tens of thousands of domains, how will a  
breach be reported?  Instead of reporting the range of IP addresses  
Fred uses, adjustment to annotations will need the tens of thousands  
of domains that Fred handles.  Does anyone really expect Fred to  
report the domains of all of his customers during a security problem?

> [...]
>>> As for tracing spoofing attacks, a MUA sees too little traffic to  
>>> be able to do such activity.
>> It is reasonable to expect the MUA will check the reputation of a  
>> few hundred thousand IP addresses prior to applying annotations.
>
> Here is where I don't follow you. I, for one, don't have a few  
> hundred thousand messages in my mailbox. In addition most of the  
> messages I have come from a minority of IP addresses.

Qualifying annotations based upon the IP addresses of the SMTP clients  
with a reputation for protecting authorizing domains requires a small  
and comprehensive list as compared to a list by the domains.  The  
alternative of guessing which domains have established exclusivity  
agreements with their email providers will result in more victims  
being given a false sense of security.

>> There are techniques that dramatically reduce the size of this  
>> list.  The alternative requires much less effective and indirect  
>> checks of many million authorizing domain names.
>

MUAs should obtain an IP address list of SMTP clients vetted by either  
an organization or a community. The overall size of a comprehensive  
list could be reduced to about 30 KB, or about the size of a small  
HTTP graphic image.

> Consuming the attacker's resources is not relevant since they can  

The DDoS attack would be directed through legitimate DNS resolvers  
that, in conjunction with MTAs, doubly obscure attacking sources.   A  
direct attack would expose the compromised systems.  SPF local-part  
macro reflected attacks would not expend a compromised system's  
resources when targeting any victim with reflected MX, TXT, A, or AAAA  
transactions.  Since this attack would not expend additional  
resources, the attack would be free for the attacker.

>>> Results obtained after inputing the *authenticated IP address* (by  
>>> way of TCP interaction) of the SMTP client into mechanisms, such  
>>> as SPF or Sender-ID, will be whether or not the SMTP client has  
>>> been *authorized*.  Only when this SMTP client has a reputation of  
>>> ensuring the Mail From or PRA originates from the user of that  
>>> domain (perhaps with click-through validation associated with the  
>>> access account), would it be safe to annotate a message as  
>>> originating from the *authorizing* domain.  Attempting to  
>>> indirectly assess SMTP clients based upon the authorizing domain  
>>> makes the assessment orders of magnitude less effective and more  
>>> expensive.
>
> implied volume of data is not what a typical MUA has in its  
> mailboxes. Thus, it has to rely on an external service. I ask again  
> the same question: what is the result that such external service  
> delivers?

While MUAs might prompt users to enter the domains they wish to trust,  
this entry would be rather perilous.  The exclusive use of the MAIL  
FROM or the PRA is not the norm, so it would be foolhardy to assume  
otherwise.  MUAs should obtain an IP address list of SMTP clients  
vetted by either an organization or a community.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 28 Feb 2009 13:14:16 +0100

Douglas Otis wrote:
> ESPs optimize profits by reducing their 
> support calls.  To do this, they might reduce erroneous rejections by 
> tweaking SPF to make guesses.  As such, it is not safe to assume that 
> because the ESP accepted a message from an authorized SMTP client, that:
>
>   B) that this authorization verifies an authorizing domain emitted the 
> message.
>
> protection of the PRA and Mail From.  Unfortunately, identifiers for the 
> SMTP client have been omitted.  It appears ESPs have agreed not hold 
> SMTP clients accountable to reduce ESP support calls.  Having some of 
> their customer's domains affected by a security breach is preferred over 
> all customer's domains being affected (even when it would be appropriate 
> for all domains).

However, choosing an ESP should involve more thinking. There are 
several reasons why end users need to trust their ESPs. If your ESP 
were malicious, they could play any sort of trick, probably also 
spoiling your bank account. Thus, I think end users should trust their 
ESPs not less than they trust their banks.

As far as I understand it, users should configure the MUA giving the 
domain of their ESP and telling it to trust auth-res headers from that 
domain only. The ESP is obviously responsible to avoid that 
counterfeit auth-res records "signed" by the ESP's domain are already 
present in the original headers. (This isn't foolproof, though: users 
who transfer their mail via, say, gmail's pop3 client, may be tempted 
to trust their original domain's records, which might be written by 
malicious authors who send to gmail directly.)

> this entry would be rather perilous.  The exclusive use of the MAIL FROM 
> or the PRA is not the norm, so it would be foolhardy to assume 
> otherwise.  MUAs should obtain an IP address list of SMTP clients vetted 
> by either an organization or a community.

I'm sorry I elided the rest of the discussion, but the last point you 
make IMHO summarizes much of the misunderstandings about reporting the 
SMTP client's IP address. Shouldn't users delegate to their ESPs the 
choice of an organization or community who maintains such vetted lists 
of SMTP clients?

In case they should, then the whole job of authenticating the SMTP 
client can be carried out by the MTA, and communicating the address is 
useless. Maintaining such vetted lists formally (if not semantically) 
resembles the work of DNSBLs, which is why I thought that an addition like
    Authentication-Results: example.com;
      dnsbl=pass zone=zen.spamhaus.org address=192.0.2.3
would have been equivalent to your proposal.

In case they should not, then MUA software needs to be revamped in 
order to accommodate that functionality. That IP address will have to 
be communicated to MUAs, obviously. However, it is still questionable 
that the auth-res header is the proper place for doing that. In 
addition, a new protocol (possibly over http?) has to be standardized 
in order to allow MUAs to deploy the vetting service that you mention.