[mail-vet-discuss] secdir review of draft-kucherawy-sender-auth-header-11.txt (fwd)

[SM]

At 09:46 29-01-2008, Murray S. Kucherawy wrote:
>From: [redacted]
>To: Murray S. Kucherawy <msk at sendmail.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