ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-vesely-dkim-joint-sigs

2010-09-18 04:57:29
On 18/Sep/10 01:43, Douglas Otis wrote:
   On 9/17/10 3:12 PM, J.D. Falk wrote:
Today's reputation systems aren't static; the operators are
constantly changing them in reaction to what the spammers
do.
Adjustments to reputation systems are necessary because spammers
keep changing tactics, attempting to get around the reputation
systems.

When DKIM is used to white-list domains, this then runs the risk
of white-listed messages being replayed and directed to recipients
not intended by the signing domain.

Indeed, if replay attacks did not exist, there would be little reasons 
to be picky about message integrity.  We would sign just "From" and 
get away with it --as some domains do.

I wonder why the idea of binding messages' signatures to their 
destination domains hasn't been considered before.  As Ian pointed 
out, this would limit replay attacks to a single destination domain.

A different, though possibly related, idea is to use sequence numbers 
of some sort.  For example, coupled with monotonically increasing 
"Message-Id"s, signatures can identify message streams consistently. 
This would require stateful verifications, though.

Such wags should be interesting for DKIM as a whole, because they do 
limit replay attacks.  It is not coincidental that they sprout on 
tackling MLMs, given the paradox these pose to DKIM, which is well 
stated in RFC 4686:

  Many mailing lists, especially those that do not modify the content
  of the message and signed header fields and hence do not invalidate
  the signature, engage in a form of signed message replay.  The use of
  body length limits and other mechanisms to enhance the survivability
  of messages effectively enhances the ability to do so.  The only
  things that distinguish this case from undesirable forms of signed
  message replay is the intent of the replayer, which cannot be
  determined by the network.

-- 
I save reputation considerations for another list...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html