Some thoughts about the third party signature discussion that happened over the last couple of weeks while I was away:
I wrote ATPS as an experiment in 2012. At the time we were still finishing DKIM (RFC 6376 was only five months earlier), and still talking about whether a third party signing solution was even possible. Doug Otis had a similar "TPA" draft out at the time, but neither of us were getting any traction from the working group. The community was quite dubious that the general idea could work, and TPA had a lot of complexity to it that I thought we could do without (or, at least, if we did need it, we could add it in later). Since I had an open source platform to play with, I decided to implement something, include it in the platform, ship it, and see what happens. I managed to get an AD to sponsor what became RFC 6541 to encourage other implementations to try it. In the years that followed, I think I only ever saw one consumer of that platform, other than me, enable the ATPS feature and try it out. I know of only Hector's code as another implementation. There have been claims that it was not "marketed" well, but I never saw any of this as something in need of marketing. If it's a feature people needed, they would ask for it and turn it on, and we would hear that it solved a problem. It wasn't hard to configure. To me, that doesn't say we did a poor job of "marketing" it, but more that a path to its success wasn't clear in the contexts where we really needed it. There are two main reasons I can see for this, as both an implementer and a consumer of this stuff, when it comes to mailing lists and the DMARC problem: (1) Scale. For mailing lists, ATPS only works if you list in your DNS all other domains that run lists to which your users subscribe. If you have a handful of users, you might be able to work this out. If you have a GMail number of users, you now have giant problems of user support and keeping that list current: "You mean I have to register every domain where I join a list? This sucks!" "I forgot to de-register a domain years ago, sorry. (And now that domain is still an authorized third party.)" "I typed the domain name wrong, how come it doesn't work?" "Why can't you auto-detect all of this?" (2) Security. ATPS doesn't specify what stuff the third party will generate as you. That third party now, practically, has one of your signing keys. Suppose you decide you trust the domain owner; do you trust the list? If you declare through ATPS that you trust ietf.org, and the list server here doesn't validate mail at ingress, then I can send unauthenticated mail through the list as you and it'll be as valid as if you signed it yourself. That might be OK for a marketing partner you're paying, but it's not awesome for free mailing lists. So I don't think it really helps us here, at least not in its current form. Unless I've misunderstood the proposal, amending ATPS to be a per-user thing only trades some of the second problem for more of the first problem. And I think the conditional signatures ideas suffer from the same two issues I identified above. I also have a vague inkling that we shouldn't be talking about ATPS in a DMARC document because that's a layering violation, in the sense that DMARC is built atop DKIM and SPF, and ATPS augments DKIM. We might get away with saying something like "You ought to consider things that make DKIM more list-tolerant", but forcing people to undertake all the DNS and user work that ATPS entails drags a lot of stuff into DMARC that we probably don't want. Personally, I think the DKIM transforms drafts stand a better chance of success. They need implementation and integration with a willing MLM, and some experimental deployments, to see for sure. The notion of DKIM transforms is also a long shot because of the complexity with which lists modify messages. This is not me saying we should pivot to work on these other things, at least not right now. I'm just skeptical that ATPS as defined can solve our problem. -MSK, participating
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
