Alessandro Vesely wrote:
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.
One suggestion a few years back when I was doing DSAP was a "target"
expectation scenario that might play a role under a SSRA (Special
Signer/Receiver Arrangement) where the DKIM signer has a way to
confirm the target address receiver is DKIM ready.
Related, I am considering of add subscriber page information regarding
ADSP and DKIM. But without a doubt, with the next 24 hours or so, our
List Server will be ADSP ready and will preempt any subscriber with a
ADSP domain at the subscriber page and during a submission to the
list. It will explore an ADSP extension tag called ASL "Allowable
Signer List" with the verifier already supports. For example, for the
ISDG.NET the ADSP record is:
dkim=all; asl=googlegroups.com,mipassoc.org;
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.
I seem to recall a small discussion regarding recording the b= hash or
the entire DKIM-Signature for tracking/tracking and/or for dupe
checking. But many already do this with message-id and if you binding
the message-id, then that serves the same purpose.
Honestly, all is these ideas are great - but it means nothing is we
don't have a consistent following in verifiers - just imagine we don't
have a sender policy that says "all mail is signed by anyone." This
would raise the bar to eliminate legacy domain spoofers/phishers that
don't sign or are totally ignorant of DKIM.
Once a signature is valid, 1st or 3rd party, we always ends up back to
a reputation or trust layer.
But we need to deal with the faults first.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html