ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: DKIM and mailing lists

2006-01-20 17:30:31

On Jan 20, 2006, at 1:06 PM, Frank Ellermann wrote:

Jim Fenton wrote:

------------------- 1/0/0
-The list server adds a signature.
-does not remove the existing signature,/
-does not modify the message
[...]
If I want to treat certain messages preferentially, perhaps because they come from the ietf-dkim mailing list, I'd like to make that decision based on a signature.

I think we're in trouble if the list signs something that is already signed. If you get a valid signature and the List-Id, why do you want a second signature from the list in addition to (or instead of) the "original" signature ?

Trusting the list-server's diligence in controlling abuse, the signature of the list-server would have greater value and this prevents simple spoofs.

Accepting the possibility that a cryptographic signature allows replay abuse, this may lead to a paradigm of protecting signatures to preserve their acceptance value. As such, a list-server should also obfuscate the original signature with say 'b=!Verified'. Obfuscation would eliminate a replication of effort and should be included within the list-server signature. This allows messages to be modified as normal. Obfuscation would also ensure the list-server prevents any replay abuse of one of the participants.

The list-server could also include a RCPT TO: hash within the signature to provide each recipient a means to delay acceptance when a message may be a replay. The RCPT TO: hash would also ensure each recipient obtains a unique message for replay abuse tracking. Closed policies still interfere with the use of a "thick" mediator. A "thin" mediator however means tracking abusive destinations will be impractical. For DKIM to have any value for acceptance, abusive replay must be overcome. Protecting the signature offers the lowest administrative overhead for achieving that goal.


Active participants in a list are likely to treat the list preferentially, and it's very easy to see who they are. So an attacker might try to spoof the list to get someone to read a message.

Yes, he'd get a throw-away domain. a PASS bound to it, and adds the List-Id to get around your guards. OTOH he's an unknown stranger from your POV, you wouldn't white list him.

All participants would need to be white-listed individually?

Indeed, the throw-away domain would be just that, a throw-away perhaps purchased months ago as their cost of advertising. Even a "picky" list-server would be unable to overcome this strategy. A stealthy list-server participant could post rather innocent looking messages containing links to topic relevant web-pages. These messages may then appear later in everyone's inbox, where the web- pages are now browser exploits, for example. :-(

The reputation protection strategy could be to not sign messages destine for where replay abuse may occur as indicated by community lists. This would instill a best practice that obfuscates incoming signatures which then replaces these signatures, especially at the MDA.

With this paradigm, had the list-server not taken ownership by signing the messages and obfuscating the incoming signatures, they may appear on a DKIM-Abuse-List or perhaps removed from a DKIM- Adopters list. When the list-server discovers their signature is being abused by a replay, they would then know which destination to report.

-Doug


_______________________________________________
ietf-dkim mailing list
http://dkim.org