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

Reply via email to