[mail-vet-discuss] secdir review
ofdraft-kucherawy-sender-auth-header-11.txt (fwd)
Paul Hoffman
paul.hoffman at domain-assurance.org
Tue Jan 29 16:21:57 PST 2008
At 11:44 AM -0800 1/29/08, Murray S. Kucherawy wrote:
>J D Falk wrote:
>>
>>Sounds like there'll need to be a whole bunch of statements about how
>>this header is only as secure as your existing email infrastructure, and
>>if your network is totally pwned then this header will probably be pwned
>>too.
>>
>
>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.
That's not how I read the discussion on SecDir. In specific:
At 9:09 AM -0500 1/29/08, Barry Leiba wrote:
>The MTAs might have little to say about the situation, depending upon the SMTP
>network topology -- there's often no authentication required for internal
>submission, and it's possible that not all of the internal MTAs and MDAs will
>deal with these headers.
>
>I can see two ways to rectify the situation:
>
>1. Have all MTAs/MDAs within the domain discard any sender-auth
>headers that are
>present if the message is not coming from another MTA within the domain. That
>prevents an internal MUA from putting one there. Of course, then the internal
>MTAs have to put them there when it's appropriate (an authenticated internal
>sender sends a legitimate message, for instance).
>
>2. Have the domain sign its sender-auth headers, so their legitimacy can be
>verified. This, of course, goes against one of the points of this
>header -- that
>of taking the burden of signature verification away from the MUA.
>
>It seems likely that if this header should become popular, malware would be
>changed to take advantage of that, and to use compromised machines to spoof
>sender-auth headers within their own domains... so this is a real threat that
>needs to be addressed. And it seems to me that (1) is the right way to do it.
>So there should be something in the security considerations describing this
>problem, and suggesting (1) as a way to deal with it.
That's more than a "security consideration".
--Paul Hoffman, Director
--Domain Assurance Council
More information about the mail-vet-discuss
mailing list