This is the review from the IETF's security directorate. The -11 draft
was submitted last week but hasn't yet been posted by the secretariat.
The results of this report will be worked into the document and a -12
draft produced, and that's the one that will go to IETF last call before
handoff to the Area Director.
Comments welcome.
---------- Forwarded message ----------
Date: Mon, 28 Jan 2008 15:23:57 -0500
From: [redacted]
To: Murray S. Kucherawy <msk(_at_)sendmail(_dot_)com>
Cc: [redacted]
Subject: secdir review of draft-kucherawy-sender-auth-header-11.txt
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. At the document editor's request, this review has been done
before IETF Last Call. Document editors and WG chairs should treat
these comments just like any other comments.
This document defines a new email header that provides a standard
way for MTAs to indicate the results of any authentication efforts
they may have performed, whether via dkim, SMTP auth, or other methods.
Unfortunately, the document does not clearly describe the purpose
of these authentication efforts. Examining the specifications for
the authentication methods seems to indicate that their main purpose
is to verify the accuracy of email header fields (mainly the From
field). However, the first paragraph of this document's Introduction
says this mechanism will allow an MUA to "provide a recommendation
to the user as to the trustworthiness of the message's origin and
content." That seems like an impossible task. How can we expect
computers to determine the trustworthiness of email content (e.g.
an email that says "Sherry is a lier and a cheat")? I'm not sure
what "determining the trustworthiness of the message's origin"
means. If it means verifying that the email was probably sent
by someone with the email address in the From field, it might
be possible. Beyond that, I'm less confident. I suggest that this
sentence be clarified. In fact, every instance of the words "trust"
or "trusted" or "trustworthy" in the document should be carefully
examined. Unless those terms are defined in the document, they are
too nebulous to convey a specific meaning in an IETF RFC.
In section 2.1, the third paragraph refers to only one propspec
per method. Actually, multiple propspecs per method are permitted.
Therefore, the final instance of "statement" should be plural.
Either that or the ABNF should be fixed to only allow one propspec.
What should an MTA do if it receives an Authentication-Results
header with a version number that it does not support? Ignore it?
Strip it? Is the behavior different for minor point revisions?
If not, why have minor point revisions? Why not just have a simple
version number?
In the ABNF definition of method, the comment says that the
method's result is represented by "value". Shouldn't that be
"result"?
In the last paragraph of section 2.2, shouldn't "mailbox" be
"addr-spec"?
The Security Considerations section does not seem to be a thorough
analysis of all possible threats against the system. For example,
it does not discuss the possibility of a malicious party using
a malformed or very long Authentication-Results header to exploit
a bug in an MTA or MUA. I suggest that a more thorough threat
analysis be included.
Another threat that I'm concerned about is that it seems that
any MTA inside the border MTA can add, delete, or modify an
Authentication-Results header without detection. In fact, an
MUA inside the border MTA can send a message with a forged
From header and an Authentication-Results header that seems
to indicate that the From header was validated by the border
MTA. In general, it seems that an MUA receiving an email that
includes an Authentication-Results header must simply trust
that the border MTA and even all MTAs and MUAs within the
border MTA are trustworthy and uncompromised. This seems like
a pretty large hole.
The term "extension identifier" is used in the document but
never clearly defined. Also, a large variety of alternate forms
for this term seem to exist: extension field, method identifier,
extension method, message authentication method name, etc.
Sometimes it seems that this term includes all method identifiers
listed in the IANA registry, sometimes it seems to only refer to
new ones defined outside of this document, sometimes only to
experimental method names. I suggest that the author decide on
one term and use it throughout, encompassing both the method names
defined in this document and new ones that may be defined in
later RFCs or used for experiments.
Shouldn't there be some restrictions (MUST, SHOULD, etc.) on
how experimental method names can be used? Otherwise, people
will start using an experimental method name and then it will
leak out onto the Internet and come into common usage, all
without an RFC having been published for it.
I don't think you want the word "emergent" in section 2.6.
Wouldn't "new" be a better word? Methods identified with
extension identifiers may be emergent when the identifier
is first defined but they won't be five years later.
Section 4.1 says that "an MUA SHOULD NOT interpret this header
field unless specifically instructed to do so by the user."
What if the user is clueless but the administrator has preconfigured
the user's system to interpret the header field? I think that
should also be supported since most users are clueless about
this sort of thing. So I suggest changing "user" to "user or
administrator".
I'm afraid that it's not reasonable to assume that users
"would not activate such a feature unless [...]". Most users
don't have a clue about any of this stuff. Most likely, they'll
leave everything at the default settings. If their administrator
tells them to change something, there's maybe a 20% chance that
they will do it (and half of those will do it wrong). There's
also the user who randomly cruises through the UI, turning
things on and off to see what happens. Yes, we can't protect
users against themselves but we should not assume that they
are all reading the RFCs! Even I, after reading the text that
I replaced with "[...]" above, am not sure I understand it.
What's "receiving MTA" supposed to mean? My border MTA?
My MDA? Something else? How on earth would I know whether
it does everything it's supposed to? I would just depend
on my administrator or ISP to tell me. At that point, we
might as well have the administrator turn on this feature!
Later in section 4.1, it says that "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
message that was authenticated." First, shouldn't the words
"should not" be capitalized? Second, where can I get that
reputation data? If it's not available today, then what's
the point in defining this header? We just said that MUAs
should not reveal the results to end users in today's world!
The example given later in that paragraph of a domain name
that "was intended to mislead" is a matter for human judgement.
I have a friend who has the domain name "opus1.com". He's
not intending to mislead. I don't know how a computer
could tell the difference. Maybe that's where the special
reputation system comes in.
Section 4.2 talks about how to handle a site policy that
rejects messages that fail authentication. It seems that
in many cases this would be a matter for MUA policy.
If so, I suppose that it's not possible to issue an
SMTP rejection. I'd suggest that you acknowledge this.
Section 5 says that header fields added on local-to-local
messages should not be deleted. Why not? Why are those
more trustworthy, especially if they come from an MUA
or loosely managed MTA (like one in a branch office)?
Section 7.2 says that each method registraton must
define one or more ptype values. Why not zero?
Section 8.1 says that MUA processing of the Authentication-
Results header should be disabled unless the user has verified
that "the MTA" is compliant. Which MTA? The Border MTA?
The MDA? That should be clearer. Also, even if the Border
MTA properly strips these headers and adds its own, an
Intermediate MTA (inside the border) could modify them
without detection. If the header is signed (one of the
"nascent" solutions to header forgery), the Intermediate
MTA could still change other headers or the body of the
message.
Section 8.2 says that the MUA may decide to record that
the sender is "valid". What does that mean? Also, I think
this section should describe some of the ways in which
spam can get through even a completely accurate mail
authentication system. For instance, a compromised
computer can send spam with a valid From address
but without the authorization of the computer's owner.
In Appendix B, "retrofit" should be "retrofitted".
In section C.3, why is the smtp.mailfrom value in the first
Authentication-Result not "sender(_at_)example(_dot_)net"? That's what's
in the From field.
In section C.4, what is "(cram-md5)" doing in the
Authentication-Results header? Section C.5 has this
also and says that its a comment field but it doesn't
appear in the ABNF.
In general, I am not sure there's much value in adding
the Authentication-Result header. First, I suspect that
most users won't know how to turn on MUA use of it.
Second, I am concerned about forgery of the header,
especially within a domain. Third, I am concerned that
misguided users and spam filters may start using the
header when the MTA isn't stripping it properly, leading
to false belief in messages with forged headers. Fifth,
as pointed out in section 8.2, even a system that always
correctly validates the From field is not of great value
without a reputation system to indicate whether validated
From addresses are reputable senders.
In spite of my qualms, I recognize that spam is a huge
problem and that email authentication is a somewhat effective
tool against it. Some of the problems described above
are very hard to solve but many can be addressed easily.
If there is rough consensus within the email community
that standardization of this header is beneficial, it
should go forward. However, as many of the items listed
above should be addressed as possible. Most of them can
be fixed by clarifying the document. The problems that
I think are hard to solve and could therefore be set aside
with a warning in the spec are:
1) Potential for Intermediate MTAs inside Border MTA
to modify message or headers.
2) Difficulty of determining accuracy or trustworthiness
of message content
3) Difficulty of determining whether a domain name or
email address is "intended to deceive"
4) Difficulty of determining whether a sender is
reputable
5) Difficulty in determining whether sender actually
intended to send a message or whether his MUA or
an MTA along a trusted path created the message
without permission
Thanks for your attempts to address the pernicious
problem of spam. Please take my comments in the
constructive manner in which they are intended.
[...]
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html