On 4/30/15 11:08 AM, Hector Santos wrote: > On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote: >> >> If OpenDKIM is popular among many big systems, it >> would make sense >> to slightly update OpenDKIM so that the "atps=y" >> option is based >> off a DMARC lookup. The change is small. >> >> Sure, if that's consensus. That would also involve >> promoting ATPS to >> the Standards Track, but to do that we'd need to see some >> hope that >> widespread deployment is likely. But we still have that >> pesky >> registration problem to deal with. > > Registration is a different situation that is tied to the > market place. It should not be a barrier to the IETF > technical protocol we wish to provide as a IETF > recommended solution. > >> Maybe Murray can explain how its setup and triggered >> in OpenDKIM. >> >> If you enable it, you just have to name which domains you >> authorize to >> sign for you. > > So if I understand RFC6541 (its unfortunate I wasn't > around during work): > > Given two identities: > > ADID Author Domain Identity (5322.From.domain) > SDID The signer domain identity to be placed in "d=" > > 1) The DKIM signer MUST add tag "atps=SDID" to DKIM-Signature > 2) The DKIM signer CAN add tag "atpsh=hash" to DKIM-Signature > > At the DKIM ATPS compliant Verifier: > > 3) It takes atps=SDID and atps=hash to do the hash(ADID, > SDID) lookup. > 4) A positive results signifies authorization, allowance. > > Correct? Dear Hector,
My initial feedback on this was ignored. The matter became worse due to demands made by IESG out of DDoS concerns. The required use of a special DKIM signature is not practical for at least two reasons. 1) The label encoding used by a first party CAN NOT be directly ascertained! (There should only be one encoding scheme.) 2) It expects mediators to establish relationships with all first party domains. (Special DKIM signatures should be replaced by DMARC assertions to allow normal DKIM signatures AND other verification methods.) Imagine offering a free service. Because of a few irresponsible ESP making false assertions about their message alignment, this then requires all secondary services to establish a database against tens of thousands of domains. This effort is absolutely reasonable for the large ESPs attempting to assert restrictive policies, it is not reasonable for tens of thousands of third-party services now expected essentially replicate this effort. TPA-Label offers a much cleaner solution that does not require the use of DKIM or SPF. Use of a special DKIM signature actually increases DDoS concerns. > In the original ATPS drafts, in step #3 would of been: > > 3) Do a ADSP lookup, if "atps=y" tag found, do hash(ADID, > SDID) lookup. > > Correct? > > Well, I think you prematurely removed the ADSP dependency. > Wish I was there to object. Making it based off DKIM > increased the adoption barriers with a DKIM change > requirement. This would be one big reason for no traction. > > Anyway, I think we can simplify this. Back when RFC5016 > was being done, an implementation debate regarding when to > do the policy lookup, under what condition. Concerns of > too much DNS wasted calls, etc. The threat analysis > RFC4686 pretty provided a consensus that the only time we > really needed to do the lookup was under the mismatch > condition: > > ADID != SDID > > Doing a lookup even under ADID == SDID condition did allow > for addition policy offerings such as: > > o Domain has no mail operations > o Domain does not sign mail > > But these events can be folded with other fail conditions > so it wasn't necessary to do a lookup for a valid 1st > party signature. After all, the Trust Lookup of SDID was > the next step in this total DKIM+POLICY+TRUST process. > > So in short, all these extended ideas for a DSAP, TPA, > ATPS, etc, can be done when the ADID != SDID condition > exist. No "atps=y" dependency on any other protocol like > ADSP, DMARC and DKIM. > > The mismatch condition is enough of a signal to run an > optional 3rd party authorization check. I understand the > reason for the "atpsh=" tag, but we can do it with a > default hashing method. Absolutely. In fact, you should be able to use a simple assertion in the DMARC record and leverage existing DKIM signatures AND other authentication schemes. I would be happy to go over what it would take for the information contained in these schemes to be compatible, but why? It seems going to the trouble of establishing third-party profiles, this effort should anticipate what might be needed to help mitigate expected abuse. (Reducing the attack surface so to speak.) My latest draft on this matter offers a simple solution requiring minimal registration << 100. Regards, Douglas Oits _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
