Hi Brandon, some quick points:
1) I was 100% concentrating on the technical protocol aspects to make
DMARC protocol complete. DMARC is currently not protocol complete. It
does not address the failure scenarios related to 3rd party
re(signers). It left loopholes that need to be closed. The
application aspects for administration is, in my technical view, a
secondary consideration. The protocol's framework need to complete.
2) If you suggest there are existing solutions to fill in the holes,
then they need to be documented in the DMARC proposed standard.It
can't be intentional "ignorant" about it. This ignorance did not work
with ADSP and it did not work with DMARC.
Based on your comments there would be a total of four methods to
consider for implementors to offer:
1) Honor the DMARC policy. No Subscriptions, nor submissions from
restrictive domains. Gandfather current members from restrictive
domains as read-only members.
2) Give DKIM private Key to authorized (re)signer,
3) Use CNAME to share a key with authorized (re)signer, and
4) Use ATPS RFC6541
Note, I intentionally left out the horrible rewriting kludge. I would
not encourage it. Provide good protocol-complete solutions and
kludges won't be necessary.
Thanks
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
On 6/15/2020 1:15 PM, Brandon Long wrote:
I don't understand what adding authorized third party signatures will add.
For a corporation, it may be possible to validate and approve a number of
third party signers... right now, that's done via DNS by either extending
SPF to include the third party, or giving the third party a DKIM key (or
better, mapping a key into your domain name space with CNAME)... or even
by smarthosting.
Any email sending vendor has to support this at this point. However, this
doesn't handle the external mailing list case, or at best it works with just
the largest providers or some limited number of lists, but I doubt our
security department would approve some random open source list to send mail
as the company.
For a large mailbox provider, the set of potential third party vendors is
very large, and would require an extensive vetting process to make it work,
and even then, you've opened it up to security issues at the weakest link.
This is basically Google's OAUTH API Verification process with estimates
that the vendor security audit cost of $15-75k... and still wouldn't handle
small mailing list providers.
The reason third party signatures don't work for mailing lists is because
they are a relay, not an origination service, and fundamentally third party
signatures only work with origination services.
One could say that the third party auth problem is the same with ARC, but
there are two major differences. For one, the question of whether to
accept an ARC hop as valid is on the receiver, not the sender, which allows
it to work with relays which are more known to the receiver than the sender.
For two, ARC is saying something very different. Third party auth is
saying "this service can act as me" while ARC is saying "this service
relayed the message
without substantive changes". It remains to be seen whether ARC is
successful at this, of course.
So, at best, third party auth for DKIM wil be a "new" way of giving a
service access that no one will support for a long time, while there are
existing
mechanisms which work today for that.
Brandon
On Sun, Jun 14, 2020 at 10:23 AM Hector Santos <hsantos=
40isdg....@dmarc.ietf.org> wrote:
When we look at DKIM and the DMARC protocol by exposing the boundary
conditions of the protocol, it helps with laying the groundwork for a
protocol-complete model.
DKIM has three possible signature states:
- NONE (no valid signature)
- 1PS (1st party valid signature, Author.domain == Signer.domain)
- 3PS (3rd party valid signature, Author.domain != Signer.domain)
DMARC has three polices:
- none
- quarantine
- reject
With these 3x3=9 states, the following table with the boundary
conditions of the protocol is established with the expected and
potential actionable result:
DMARC POLICY
+===================================================+
|////// | p=NONE | p=QUARANTINE | p=REJECT |
|===================================================|
D | NONE | fail-pass | fail-filter | fail-reject |
K |-------+------------+------------------------------|
I | 1PS | pass | pass | pass |
M |-------+------------+------------------------------|
| 3PS | fail-pass | fail-filter | fail-reject |
+===================================================+
Note: I intentionally left out SPF conditions for NONE, NEUTRAL,
SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states.
For this exercise, we are assuming DMARC/SPF alignment is in play
and failure can be for any DMARC known reason including the 3PS failed
states.
The states for DKIM none and 1PS are expected protocol conditions.
DMARC describes these conditions. But the DKIM 3PS conditions are not
described and are subject to questionable actions because of the
possible false positives results.
The 3PS failures occur because of the dearth for an Authorized Third
party Signature protocol. DMARC does not offer 3rd party signature
solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But
they did not restrict an ADD-ON extension to the protocol.
ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and
when DMARC replaced ADSP, it equally applies to DMARC as well as an
extension. We do not need to get into the specific ATPS protocol
details on how to authorize a 3rd party signer. Any "ATPS-like"
protocol will only need to answer one question:
Is the 3rd party (re)signer authorized? Yes or NO
With this consideration, the table has one additional 3PS-AUTH row
meaning Yes, the 3rd party (re)signer domain was authorized by the
author domain.
DMARC POLICY W/ ATPS
+======================================================+
|////// | p=NONE | p=QUARANTINE | p=REJECT |
|======================================================|
D | NONE | fail-pass | fail-filter | fail-reject |
K |----------+------------+------------------------------|
I | 1PS | pass | pass | pass |
M |----------+------------+------------------------------|
| 3PS | fail-pass | fail-filter | fail-reject |
|----------+------------+------------------------------|
| 3PS-AUTH | pass | pass | pass |
+======================================================+
Overall, as it was originally conceived, the DKIM Policy model can not
ignore ATPS conditions because as you can see above, it would not be
protocol-complete -- it is missing the 3PS-AUTH conditions.
While ADSP is a specific RFC proposed protocol, I am using it as an
acronym for any authorizing third party signature concept:
Result = DKIM_ATPS(author.domain, signer.domain)
Lets finish that part of the DKIM model.
Thanks
[1] https://tools.ietf.orgy/html/rfc5617
[2] https://tools.ietf.org/html/rfc6541
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
