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
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html