At 09:46 29-01-2008, Murray S. Kucherawy wrote:
From: [redacted]
To: Murray S. Kucherawy <msk(_at_)sendmail(_dot_)com>
Cc: [redacted]
Subject: secdir review of draft-kucherawy-sender-auth-header-11.txt
[snip]
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.
I suggest dropping "trustworthiness of content" based on these
comments. It might be easier to have the header convey the results
of authentication methods to MUAs without mentioning message origin
and leave it to the MUA to make a determination about the message.
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?
If the MTA ignores an invalid header and ignores it, this can be
construed as a threat (re: comments about malformed headers in the
review). We come down to the point where we have to strip the header
if the format/version is not supported.
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.
This could be addressed together with the above paragraph.
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.
It's difficult to prevent the above unless the header is signed so
that it can be verified by the MUA. It's a valid issue as the threat
is greater than the amount of trust we are pushing in through the header.
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
Good point. We are getting into UI design here. Some may point out
that it would be out of scope for a RFC.
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.
This header is also useful to downstream filters. The introduction
puts an emphasis on MUAs.
If we get into where to get the reputation data, we'll have to cover
the security concerns for that as well.
[snip]
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:
It may be better to reduce the scope of this header than to address
all the issues mentioned in the review unless someone has an idea on
how to solve these problems.
At 11:44 29-01-2008, Murray S. Kucherawy wrote:
Essentially, that's what it boils down to: a more precise
Introduction and a more lengthy Security Considerations, and then a
number of lesser tweaks throughout the document.
I read it as much more than that.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html