Poison Pills: The death of DKIM SSP

---

For those who remember the classic ending in Planet Of the Apes, where Heston finally realizes he never left earth seeing the crumbled Statue of Liberty sticking out of the beach sand, he cries in despair:

"They finally did it! Oh no! Those Bastards finally did it!"

Its exactly how I felt when the DKIM working group was commandeered by a handful of business related concerns to finally destroy the DKIM SSP protocol proposal.

The way they did it was nothing short of a brilliant strategy in injecting a poison pill.

For awhile there, it seemed the momentum was on the side of SSP. The SSP-01 specification was making sense, developers began to feel confidence to implement it feeling there was no way in hell, it will change much more.

But all of sudden BANG - a competitive [draft] specification called ASP was introduce - a poison pill. ASP was so BAD, it is fairly obvious no one will use it.

But the ASP group was powerful enough to get the SSP authors to rewrite their own SSP specification with nearly all the same content!! It made you wonder WHO copied WHO!  [ASP was renamed ADSP as a proposed standard RFC 5617 https://datatracker.ietf.org/doc/html/rfc5617]

ASP is so bad, not even the ASP principal author is supporting it for his new Reputation $$$$ business services. It's not part of the VBR specification!. You wonder why? Well, anything SSP-related would water down his VBR system. Most systems would simply not need this REPUTATION service.

In some way, I am happy it happen. Now I can move on. The ASP people should be given credit for killing SSP. I just wonder if they have enough sleeping pills on hand - they are going to need it.

Post Note:

It is now April 4. 2023. I am hoping to resurrect ATPS [RFC 6541 https://datatracker.ietf.org/doc/html/rfc6541] as an add-on for the DKIM Policy protocols ADSP and DMARC which also provides a reporting mechanism.  Updating ATPS to piggyback off the ADSP or DMARC record lookup.  DNS-based Mail Security applications have grown since this post in 2008; SPF, DKIM, ADSP, replaced by DMARC are the SMTP DNS lookup overhead expected by receivers in the name of Sender/Author Domain Email Security (SADES).

Is DKIM safe without a strong policy framework? Part 2

---

Last year, I touched based with the DKIM securities issues and it major lack of tieing in policy considerations (SSP):

Is DKIM safe without a strong policy framework?

Since last year, the SSP spec has evolved to something that is surreal in terms of its functional specifications. It is overly complex and quite frankly, I don't think even a PHD can understand its purpose.

Today, believe it not, it is still being rehashed, same debates, same arguments, same people on one side of the SSP (CONS) and same people on the other side of SSP (PROS). It is like nothing was accomplished. And just like it existed on day 1, the same problems with DKIM sans SSP, exist today. Its only coming up again now because it will be on the table at the next IETF meeting.

When I wrote the alternative SSP protocol called DSAP, it was specifically written to address all the key security issues.

After discussions with the author of SSP and the IETF-DKIM chairs, I agree to support SSP if it covered all the basic security issues. The author did add the consideration's (although in extremely complex ways), so I opted to abandon any follow ups to my far simply, more concise DSAP I-D proposal.

Today, I am seriously considering of revisiting the DSAP proposal. If the IETF and the IETF-DKIM can't get SSP ratisfied (even with its complexities), I might just throw in this monkey wrench and see how it flies.