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 <hsantos= 40isdg....@dmarc.ietf.org> 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 <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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
