On 6/25/2020 11:20 PM, John Levine wrote:
In article <caj4xoyecbh4ycofhzmv+a0336aifx55blvsdh-u21kkj+gr...@mail.gmail.com>
you write:
B) Specifying the specific Intermediary in the Intermediary Field. This
would indicate that the users domain recognizes that the user uses the
intermediary and by policy exempts this use even though it breaks both DKIM
and SPF validation. The receiving domain would need to recognize some
potential risk of malicious modifications or additions to the message.
Sounds like what I proposed several years ago:
https://tools.ietf.org/html/draft-levine-dkim-conditional-03
Ideally, we should offer support for two methods:
1) The non-DNS conditional method,
2) The simpler ATPS DNS method.
The 1st one is more radical code change for additional "double" DKIM
signing logic. You will have a segment of the population where this
is either not be possibility and/or delayed until it can be done. It
also comes with security warning from the author.
The 2nd one is simple and plug and play as a DNS lookup challenge
method. It does not require DKIM changes. It will require slight
modifications to the DMARC verifier to look for the optional DMARC
extension "atps=y" tag for 3rd party signing conditions and
authorization check.
I can support #1 because there will be IETF folks who will say #2 does
not scale and the DNS lookup overhead can be high with NXDOMAIN
results. The latter would certainly be true during the early migration
period in the same way it was true with SPF, ADSP and now ADSP The
same was will be true with ATPS with NXDOMAIN results. Over time, we
will see the payoff as more domains will support the officially IETF
sanction protocols described in a protocol complete DMARC-PS.
As to ATPS not being scalable? That is just a question more related
to DNS storage and management. But even so, having both will address
all scales and wider implementations where you will have a migration
period and the easier one will probably be implemented first to get a
proof of concept and then perhaps adding conditional support for
higher scale needs.
But I won't repeat what has happen in the past. I won't support #1
unless the author is serious about DKIM Policy and show he is ready to
champion the protocol rather than use this as a way to poison the
DKIM/DMARC policy effort with a chaotic and self-admission unsecured
DKIM add-on with no real intention to complete and support. The
security section #1 will need to be review to address its described
replay potential.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
