[dmarc-ietf] Third party signatures

["Murray S. Kucherawy" <[e-mail]>]

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