Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
On 6/16/2020 2:19 PM, Brandon Long wrote: So you think we should include https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in the actual spec? 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 -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
So you think we should include https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in the actual spec? Brandon On Tue, Jun 16, 2020 at 10:26 AM Hector Santos wrote: > 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 > 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 |---++--
Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
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 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 1
[dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
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
