Re: [APPS-REVIEW] secdir review of draft-kucherawy-sender-auth-header-20

On Jan 25, 2009, at 7:52 AM, Barry Leiba wrote:

> I have reviewed this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG.  These comments were written primarily for the benefit of the  
> security area directors.  Document editors and WG chairs should  
> treat these comments just like any other last call comments.
>
> Specifically, I've been asked to review draft-kucherawy-sender-auth- 
> header-20, after having reviewed the -18 revision, and to consider  
> draft-otis-auth-header-sec-issues-00 in the review.  I'm also  
> copying this review to the apps-review list, since it's relevant  
> there.
>
> I've looked at the diffs between the -18 and -20 versions, to make  
> sure I didn't miss any changes, and I've reviewed the -20 version as  
> a whole.  I've also looked at the comments and questions that have  
> come up during IESG evaluation.
>
> My evaluation of the document stands from the -18 version -- the -19  
> and -20 revisions have made clarifications over -18, in response to  
> other comments, and that's good.  But the document was basically  
> sound then, and reflected rough consensus of the participants from  
> the email-developer community, and still does.
>
> Considering draft-otis-auth-header-sec-issues-00: Doug's main point  
> appears to involve a disagreement with Murray's decision not to  
> include the IP address, for SPF and Sender-ID cases (for simplicity,  
> I'll just say "SPF" to refer to both in this review).  Murray  
> instead includes only the domain that has been verified (or not)  
> *using* the IP address.  His complaint is that the header field  
> "fails to offer the authenticated entity being trusted in the  
> exchange, the IP address of the SMTP client."  In other words, Doug  
> considers that it's the IP address, not the ADMD, that has been  
> "authenticated".
>
> I disagree, but this is a tricky area, because we're not wading in a  
> typical sort of authentication pool here -- SPF is actually blending  
> identity, authentication, and authorization.  As I see it, the SPF  
> model is that the *identity* to be authenticated is taken from the  
> SMTP MAIL FROM command (for Sender-ID it's derived through the PRA  
> algorithm), the IP address supplies the authentication  
> *credentials*, and the DNS lookup both verifies the credentials  
> (completing the authentication) and returns the authorization  
> information in one, combined response ("the entity with these  
> credentials is authorized to send mail on behalf of the identity  
> 'example.com'.").

The IP address of the SMTP is being authorized by a domain.  It is not  
known whether the domain intended the authorization to have been based  
upon the Mail From or the PRA due to conflicting RFCs.  Although the  
IESG added a warning about this conflict within the respective RFCs,  
it seems unlikely the warning convinced a substantial portion of those  
who published an SPF record, to then also add a record intended to  
support Sender-ID.

The statement made within RFC 4406 in regard to unintended use of the  
SPF record is as follows:
,----
In order to provide compatibility for these domains, Sender ID  
implementations SHOULD interpret the version prefix "v=spf1" as  
equivalent to "spf2.0/mfrom,pra", provided no record starting with  
"spf2.0" exists. ...
If the information in a "v=spf1" record is not correct for a PRA  
check, administrators SHOULD publish either an "spf2.0/pra" record  
with correct information or an "spf2.0/pra ?all" record indicating  
that the result of a PRA check is explicitly inconclusive.
'----

While this was a way to adopt RFC 4406 without waiting for explicit  
support, this also created animosity among those not wanting the scope  
of SPF record changed by what they viewed as interlopers.  While the  
IESG warning may have been well intended to better ensure email  
acceptance, it would be dangerous to also assume this warning  
rectified existing conflicts between RFC 4408 and RFC 4406.

Secondly, the initial intent of this record was primarily to mitigate  
backscatter (currently mitigated by RFC 3834 with greater delivery  
integrity).  It remains doubtful that a domain wishing to avoid  
backscatter, also asserts that their authorization of an SMTP client  
ensures _only_ their domain controls the use of Mail From parameter or  
PRA header field.  Any assumption that Authorization of an SMTP client  
represents Authentication of the authorizing domain as a message  
source ignores these dangerous and likely incorrect assumptions!

> Of course, it's entirely reasonable to want the credentials to be  
> preserved, since they're not secret.  I see nothing wrong with  
> including the IP address, and I wonder why Murray has chosen not  
> to.  That said, I agree with the approach that this field is meant  
> to convey the *results* of application of an "authentication"  
> algorithm, and not to give the MUA what it needs to re-run the  
> authentication. I'll note that the same is true with the application  
> of this to DKIM: the header field described here does not contain  
> all the information provided to the DKIM validator.
>
> So, while I see no harm in including the IP address, I have no  
> problem with the decision not to.  I also note that it can be added  
> as an extension, if there's demand for that from the MUA vendors.   
> There doesn't seem to be, at this point.

The problem of not including the IP address is many.  The header is  
labeled "Authentication-Results".  By excluding the _only_  
authenticated source identity, the IP address of the SMTP client, the  
header becomes dangerously misleading.  When there are two entities  
depicted, a recipient is likely to question which element was  
authenticated.  In addition, it is the SMTP client being trusted to  
control the use of parameters or header fields that contain the  
authorizing domain.  When this trust is not upheld, the reputation of  
the SMTP client should be directly affected, and not that of the  
domain.  If access to the SMTP client has been compromised, direct  
application of SMTP client reputation offers a means for the rapid  
protection across all domains who may have authorized the SMTP client.

Assessing SMTP client reputation against the authorizing domains is  
unfair for several reasons.  The domain is unlikely to control the  
SMTP client and therefore is unaware of any security breach.  Blocking  
the entire domain also prevents communication through any other secure  
SMTP client, which makes assessments of the SMTP client by the  
authorizing domain highly disruptive and unlikely impractical!

> There's the issue of needing the IP address to properly assess  
> reputation.  DNS black/white lists (see draft-irtf-asrg-dnsbl) use  
> the IP address as a reputation key because it's what they have.  The  
> whole *point* of SPF is to translate the IP address into a confirmed  
> domain name, to have a more useful reputation key, and this header  
> field supports that.

Strongly disagree.   The intent of the Authentication-Results header  
is for the presentation the results of the methods _after the  
reputation of the message's authenticated origination was checked_.   
The only authenticated identifier of the message's origination is the  
IP address of the SMTP client in the case of SPF and Sender-ID.  The  
draft does not mandate that the reputation of the source be checked  
prior to adding this header.  In fact the example given for look-alike  
domains indicates an expectation that the header is added without  
prior reputation checks regarding what is safe to be annotated.  The  
draft only requires the reputation of the message source be checked  
prior to revealing these results to users, which is normally a  
function of an application down stream from that of the border MTA.   
Although the border MTA that will be making acceptance assessments,  
these assessments may not relate to the safe source annotations of  
Mail From or PRA parameters or header fields.

> That said, there are result values that do not allow the use of the  
> ADMD as a key to a reputation check: "none" and "neutral", for  
> example, explicitly refuse to tie the IP address to the domain  
> name.  In such cases it might be useful to have the IP address  
> available for fall-back reputation checks.

The IP address of the SMTP client is the only reputation check that  
should be made!  While there are hundreds of millions of domains,  
there are about 1.5 million SMTP clients that earn good reputations.   
The issue is not about which message is accepted, (a function of the  
border MTA), this is about what domain can be safely revealed to  
users.  Whether the SMTP client protects these fields is the essential  
question that needs to checked.  Appendix D reaches several incorrect  
conclusions, primarily based upon assessments about whether a message  
should be accepted, but not about which parameters or fields should be  
highlighted to users as the source of the message.  With malware being  
so rampant and polymorphic, the source of an item represents an  
extremely critical aspect of security these days.  It is not safe to  
assume that malware can always be detected.  The malware can come in  
the form documents, images, or videos that many incorrectly consider  
inherently safe.

> On the other hand, it's likely that the mail system will have done  
> other checks at the domain boundary besides just SPF.  Putting the  
> responsibility for IP-address-based checks in the MUA is probably  
> unwise anyway.

The draft places this responsibility ONLY on the application that is  
revealing the results!  There are NO assurances within the header that  
any reputation checks have even been made!   Preventing a reputation  
check of the SMTP client by the MUA for either SPF or Sender-ID  
methods is extremely unwise and will endanger users.

> Doug also worries about the use of the "local part" in SPF cases.  I  
> know that Doug is bothered by the local-part stuff in general, and I  
> agree with some of his concerns.  I think, though, that those  
> concerns aren't relevant to this document -- the document, again, is  
> reflecting the *results* of the SPF check, which may or may not  
> involve the local part.  This document is not *adding* anything in  
> that regard.

Actually it does increase the concerns related to the use of the local- 
part macros available within SPF.  This draft adds a stipulation that  
local-part annotations be "authenticated" which will be interpreted to  
mean that local-part macros must be used.  In essence, the entire SPF  
SMTP client IP address authorization scheme MUST BE REPEATED for every  
user within a domain!  In addition, many of the related transactions  
are likely to occur as a result of a cached SPF record.  The amount of  
DNS traffic this generates might even saturate OC192 connections, let  
alone swamp victim DNS servers.  This enables a free attack while  
spamming!

> Finally, Doug appears to dislike the use of the word  
> "authentication" here, and I agree with him.  As I said above, SPF  
> (for example) isn't *really* an authentication system, and it's  
> unfortunate that we've fallen into using that term for it.  But the  
> fact is that we *have* fallen into it, and I think there'd be more  
> damage done by trying to use a different term than there is by using  
> the term that's come to be accepted, and to acknowledge that it's  
> not strictly correct.

The dangers are to recipients that are about to see these  
misrepresented results as a result of this draft.  At least getting  
the terminology correct now will allow a better understanding of the  
risks related to the methods being displayed.

> So, here's the bottom line:
> 1. I think draft-kucherawy-sender-auth-header-20 is ready to go as  
> it is.

Strongly disagree.

> 2. I'd like it if we weren't calling all this "authentication", but  
> I don't see any way around it and I recommend that it NOT be changed.

Why?

> 3. I wouldn't object to the inclusion of the IP address in the  
> header field for SPF and Sender-ID cases, but I don't think it's  
> necessary and support the decision not to include it.

Not including the IP address will mostly likely become a basis for an  
appeal.  There is no desire to impugn the integrity of those involved  
in the consensus building process related to this draft, but there is  
also reason to be believe special interests were influential in  
shaping this consensus, where the general good of the public and the  
Internet was not properly considered.  My humble apologies to those  
offended by an appeal not to accept the consensus for this draft.  Two  
years of misrepresenting a method intended to provide an allusion of  
security, that also makes mitigating security breaches impractical,  
can not justify the dangerous decisions that shaped this draft.

-Doug
_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW@ietf.org
https://www.ietf.org/mailman/listinfo/apps-review