Subject: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.

From: Hector Santos <[email-masked]>
Date: Sun, 14 Jun 2020 13:23:29 -0400

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

---

From: Brandon Long <[email-masked]>
Date: Mon, 15 Jun 2020 10:15:20 -0700

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=
[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 16 Jun 2020 13:26:32 -0400

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

---

From: Brandon Long <[email-masked]>
Date: Tue, 16 Jun 2020 11:19:25 -0700

So you think we should include
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in
the actual spec?

Brandon

---

From: Hector Santos <[email-masked]>
Date: Wed, 17 Jun 2020 12:31:21 -0400

> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in

In essence, with IETF review to update, clarify, extract parts, 
simplify, I think there are elements that are candidates as a MUST 
addition to the spec. They would address the remaining states in the 
protocol's framework.

With a quick review, my direct involvement experience with the WG ATPS 
vs TPA proposals, I would take exception to the statement "TPA is 
intended to replace RFC6541."  While it may be the wiki author's 
opinion, it was not what I experienced in the WG.  I found the TPA 
proposal to be complex and a hard to read draft. I believe it also 
included trust assessment concepts as well.  ATPS was 16 pages. TPA is 
40 pages.  ATPS was a much simpler protocol to implement asking the 
basic question "Is this 3rd party (re)signer domain authorized?"  ATPS 
was implemented in my product line, not TPA. I don't know where TPA 
was implemented.  With the TPA proposal's author MIA today, how would 
it work? Someone else take it over? Nonetheless, it should be added to 
the list of solutions to review.

Thanks