Re: Comments requested on recent appeal to the IESG

On Feb 19, 2009, at 6:04 PM, Dave CROCKER wrote:
> The IESG wrote:
> > The IESG has received an appeal regarding the previously approved  
> > draft-kucherawy-sender-auth-header-20.  The appeal text can be  
> > found here:
> >   http://www.ietf.org/IESG/APPEALS/appeal-otis-2009-02-16.txt
> This note offers comments on the appeal, draft-otis-auth-header- 
> appeal-00, which has been lodged against standardization of draft- 
> kucherawy-sender-auth-header-20.
> This appeal lacks merit on basic points.
>
> As a technical criticism, the appeal is confused and lacks  
> substance.  The conclusions appear to be based on fundamentally mis- 
> reading of basic technical details of the specification.  At best,  
> the appeal makes the mistake of wanting to kill the messenger,  
> rather than  the message's author. That is, the appeal's authors  
> appear to have concerns with certain types of report content, rather  
> than with the mechanism of doing reporting.  Yet auth-res is merely  
> the mechanism, a common conduit for reporting a class of related  
> information.
Dave,

Section 4.1 of this draft places the onus of checking associated  
reputations of "authenticated origin identifiers" on the MUA prior to  
revealing the content of the Authentication-Results header, but then  
fails to offer the necessary information for satisfying this  
requirement.  Unfortunately, this draft's many confusing references to  
authorization mechanisms as authentication still does not offer, with  
any reasonable certainty, that an authorizing domain originated a  
message.  The only weakly "authenticated origin identity" for either  
SPF or Sender-ID is the IP address of the SMTP client being authorized  
by an SPF record.  When the SPF-SMTP-client authorization schemes were  
introduced, a client's failure to be authorized was to provide a basis  
for not accepting the message.
> Indeed, the appeal is dominated by criticisms of SPF and Sender-ID.  
> The appeal's authors should express their concerns with those  
> communities of interest, rather than with a mechanism that merely  
> carries information that is generated by other mechanisms.
The appeal attempts to clarify that *authorization* does not represent  
*authentication*.   An authenticated SMTP client does not imply that  
it is authorized to issue a domain's message, neither does an  
authorized SMTP client imply that a domain offering authorization has  
therefore originated the message.   It is the origin of the message  
and its role in protecting originating identifiers that is being  
trusted.  The reputation of the "authenticated origin identity"  
ensuring this protection is what MUAs should depend upon.  Look-alike  
attacks should not be accepted by border MTAs, but can still be  
thwarted proactively by the MUA with folder placement.
> As a statement of preference, the appeal lacks support.  Contrary to  
> the appeal authors' perspective, the bulk of the email reporting  
> operations community find this mechanism helpful, in its current  
> form.  Whatever possible downsides the appeal's authors envision, it  
> has not yet come to pass, over a long period of use.
A desire to exclude the IP address of the SMTP client is likely aimed  
at avoiding repercussions that occur when issuing abusive messages.   
Rather than the reputation of a provider's ability to protect the use  
of a domain, the domain instead is expected to accrue the negative  
reputations.  Unfairly assigning negative reputations to a domain not  
originating abusive messages can be disruptive and may invite  
litigations.
> Detailed comments follow:
>
> > For such use, it is crucial to include within an "authenticated- 
> > results"  header, a truly authenticated identity.
> Auth-res is specified as operating within a trust domain.  It  
> explicitly asserts the need for trusting the source of the report  
> and the path from the report generator to the report consumer.  As  
> such, there is no obvious basis for claiming that further  
> authentication of the report is needed.
Section 4.1 correctly provides a basis for needing the "authenticated  
origin identifier".  *Authorization* is not *authentication*.
> > The draft acknowledges that it confuses authorization with  
> > authentication in section 1.5.2.
> No it does not. There is no language in 1.5.2 that describes or  
> acknowledges any confusion.  The only relevant text in that section  
> is "this proposal groups them both into a single header field".
Please review section 1.5.2 and then the many places where  
*authorization* is then referred to as *authentication*.  The draft  
places all results into a header labeled "Authentication-Results"  
where the only identifier offered is that of the authorizing domain,  
and not that of the authenticated IP address of the SMTP client for  
Sender-ID or SPF.
> Consequently it appears that the real confusion is with the authors  
> of the appeal, who confuse an explicit decision to allow two types  
> of information to cohabit, with inability to distinguish between the  
> two types of information.
The concern is over the explicit decision to exclude the authenticated  
SMTP client identifier in lieu of a domain offering authorization "as  
if" it represents an *authenticated* identifier.  Providers using this  
omission to elude accountability for issuing abuse will imperil  
recipients with misleading information.  This omission leaves  
recipients more prone to confidence schemes that might be aimed at  
inviting recipients to open malware or reveal  credentials.
> > This confusion has lead the draft to incorrectly elevate the  
> > authorization of  an SMTP client into the authentication of an  
> > email-address domain.
> This language implies (or states directly) that the subject  
> specification is performing authorization and/or authentications  
> functions.  The spec does nothing of the sort.  It conveys  
> information, about functions performed by supplying mechanisms.   
> It's only active function, beyond that, is to map some information  
> into canonical form.  If the appeal's authors are claiming that this  
> mapping function somehow turns authorization information into  
> authentication information, they need to supply the particulars.
The mapping intentionally excludes authenticated input information  
that will be lost.  This information forms the basis for the mechanism  
being reported.  The MUA is required by the draft to check the  
reputation of the authenticated identifier, the IP address of the SMTP  
client.  There is no other way to regenerate this information at the  
MUA.  Nor is there an out-of-band mechanism which can reliably pass  
this information.   If the author of draft-kucherawy-sender-auth- 
header knows of such a mechanism, it should be included in the draft.
Depending upon headers that are not signed, not validated, and  
impossible to trust is not workable.  This issue is not about whether  
to block a message, it is about whether to reveal this header's results.
> More likely, the appeal's authors need to distinguish report  
> conveyance from report generation.  They need to pursue their  
> concerns about particular message security analysis functions with  
> the folks responsible for particular functions, whether path  
> registration based, message authentication crypto-based or whatever  
> particular services they are actually unhappy with.
The concern in this case is with the exclusion of essential and  
necessary input information by the reporting mechanism.  The omission  
is input information passed to the authorization mechanism.  The  
exclusion of this information is not the fault of the authorization  
mechanisms, as is being suggested.
> > Elevating the *authorization* of the SMTP client into the  
> > *authentication* of  an email-address domain incorrectly assumes  
> > current email practices adequately restrict the use of an email- 
> > address domain based upon the originating IP address of the SMTP  
> > client.  In an era of carrier grade NATs, virtual servers,  
> > aggregated services, and other techniques that overload the IP  
> > address, this assumption is neither safe nor practical.
> > Although the draft explicitly declares Sender-ID and SPF as the  
> > authorization of the transmitting SMTP client, it fails to offer  
> > the authenticated identity being trusted.
> The draft does not make that declaration.  It states that Sender-ID  
> and SPF make that declaration.  Again, confusing message with  
> messenger.
The issue is not about what Sender-ID or SPF declare, the concern is  
about vital information being omitted by this draft.
> > A truly authenticated identity is essential for reputation  
> > assessments which section 4.1 indicates should be made prior to  
> > results being revealed.
> I don't understand what significance this statement has.
It would be a bad practice to assign reputations based upon the  
actions of others.   When a domain authorizes an SMTP client (it  
remains uncertain if such an authorization had been made), it would be  
an unfair practice to impact the reputation of these domains for  
messages they may not have originated.  The issue is strictly the  
concealment of the authorization inputs.
> Concerning this following portion of the appeal:
>
> > 1.  Introduction
> >
> > In the requested review of [I-D.otis-auth-header-sec-issues], Barry  
> > Leiba made the following remarks:
> > ...
> > Since Sender-ID permits the use of either version of the SPF  
> > records to be applied against the PRA, version 2 records must then  
> > be published whenever authorization of a PRA is not intended.  This  
> > retro-active mandate is to prevent the misapplication of SPF  
> > [RFC4408] records against PRA header fields.  The conflict as to  
> > whether just the Mail From or the PRA has been authorized by SPF  
> > version 1 records has left the intended scope of the SPF record in  
> > doubt.
> It has no discernible relevance to the auth-res specification.  At  
> best, it has some relevance to mechanisms that produce output that  
> is carried by auth-res. The appeal's authors should therefore  
> address their concerns with the relevant specifications and  
> authors.  Auth-res isn't the venue for this.
Raising this issue was to clarify the point that *authorization*,  
especially uncertain authorization, is NOT *authentication*.  An  
"authenticated origin identity", as required by the draft, is  
essential for fair and safe assessments prior to revealing this  
header's results.
> > The [I-D.kucherawy-sender-auth-header] fails to indicate which  
> > version of an SPF record had been discovered, or whether any record  
> > had been discovered allowing recipients a means to gauge risk.
> Auth-res carries the information it is given.  If SPF or Sender-ID  
> should report different information, the appeal's authors should  
> discuss this with the SPF and Sender-ID community.
The header omits the essential *input* given to SPF or Sender-ID  
processes.  The issue of omission pertains only to the Authentication- 
Results draft.
> >  [I-D.kucherawy-sender-auth-header] introduces a header field,  
> > which because of its label, can mislead recipients into believing  
> > that it contains "Authentication-Results".
> The appeal's authors have nicely demonstrated that almost anything  
> can be confused.  So an abstract fear of possible, future confusion  
> is a pretty weak argument for (or against) anything.
It is both the label and the omission of essential information that is  
dangerously misleading.
> In the case of Auth-res, there is already an established track  
> record, with no indication that the feared confusion due to the  
> header field's name, has occurred.
The concern is over the lack of protection that the omission of  
essential information creates.  There is a fairly long track record of  
recipients and MUAs being mislead.
> In addition, as a matter of simple vocabulary semantics, the chosen  
> field name accurately represents the role this carried information  
> plays.
A field named "senderid" does not in any way indicate an authorization  
role.  Roles would be less confusing had the input information not  
been omitted.
> > Without the presence of an authenticated identity within the  
> > Authenticated-Results header, there can not be any practical or  
> > timely remedy against compromised SMTP client access or BGP spoofing.
> At best, the appeal's authors are confusing a possible need for  
> independent authentication, between report creator and report  
> consumer, with the contents of the report itself.  Auth-res  
> specifies the report contents.  If the appeal's authors are concerns  
> about authenticating the contents, they should pursue a separate  
> specific and garner support for it.
The issue is about omitting input given to the authorization process.   
After all, it is the SMTP client identified by its IP address that is  
trusted to protect the use of the email-addresses referencing the  
authorization.
> >  The places within the [I-D.kucherawy-sender-auth-header] that  
> > purport either Sender-ID or SPF as authenticating the originating  
> > domain overlook the
> Auth-res "purports" nothing of the kind.
Section 2.4.3 includes an example.  Here the sender-auth-header draft  
purports that SPF or Sender-ID as offering not just authenticated  
domains, but also authenticated local-parts!
,---
If the retrieved sender policies used to evaluate [SPF] and [SENDERID]  
do not contain explicit provisions for authenticating the local-part  
(see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported  
along with results for these mechanisms SHOULD NOT include the local- 
part.
'---

> > 2.  IPv6, SPF macros, and local-parts
> Linking IPv6 with Auth-Res is creative, but spurious.
The draft's requirement to exclude the local-part unless  
"authenticated" represents an incentive to use a dangerous mechanism,  
as well as incorrectly purporting this to be authenticated.
> > Unfortunately, the Authentication-Header draft may actually  
> > encourage use of this dangerous local-part macro.  Section 2.4.3  
> > requires local- part authentication before it is to be included  
> > within the Authentication-Results header.
> The relevant language in the spec prohibits including a field, in an  
> authentication report, if it has not been authenticated.  All that  
> that encourages is authentication. Extrapolating that requirement  
> into encouraging
> use of that field is without basis or merit.
It is rather naive to expect senders will not seek greater prominence  
that might be achieved with a greater amount of annotation.
> > 3.  Recommended Modifications
> >  Change Section 2.4.3 FROM:
> > ...
> > TO:
> > To discourage exploitation risks, the entity that has been  
> > authenticated (the IP address of the SMTP client) SHOULD BE included.
> This fundamentally changes the meaning of that section of the  
> specification and, instead moves into active role in the internals  
> of the reporting mechanism.
Including the only authenticated origin identity used as an input to a  
mechanism should not be considered in any way internal to that  
mechanism.  This is not any different from that of the "iprev"  
mechanism.  Unfortunately, the "iprev" mechanism may impose excessive  
overhead due to nature of the reverse namespace.
> >  TO:
> >
> >  End users making direct use of this header field may inadvertently  
> > trust information that has not been properly vetted.  [SPF] results  
> > SHOULD BE handled as specified by section 3.4.3.
> This is the same confusion of venues as cited above.
The Authentication-Results draft is responsible for omitting the input  
provided the authorization mechanism.  It is not the authorization  
mechanism itself that is responsible for the omission.
The goal of the appeal is to better ensure information is available  
that is required to assess the reputation of the "authenticated origin  
identity" as specified by section 4.1.  The presence of this  
information will not be of harm to recipients, and will better ensure  
their safety as well as that of the domain.  The issue is only whether  
to display or not the results of this header at the MUA after checking  
the reputation of its source.  In order to perform this check, the  
"authenticated origin identity" must be clearly represented in the  
trusted headers.
The IESG faces the hard decision of whether they are to act in the  
greater interests of better protecting millions of recipients, or  
acquiesce to the interests of influential providers acting out of self  
interest.
Douglas Otis and Dave Rand

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf