[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at ietf.org
https://www.ietf.org/mailman/listinfo/apps-review