On Mon, May 1, 2023 at 8:23 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
> 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. > Just wanted to voice agreement on both key points. > > 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. > Also agreement in these points. One possible way to understand this space might be to create a table on trust relationships. For example, an enterprise domain conceptually might be willing to have an outbound gateway sign on its behalf or be willing to delegate via something like ATPS. Potentially there might be a similar relationship for ESPs and their customers. Other senders will have a much more restrictive trust relationship. And this is all in the abstract as others on this list understand outbound gateway and ESPs understand their respective members of the mailflow better than I do. As for DKIM transforms, I just wanted to suggest that this ought to be future work for DKIM WG. -Wei > > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
