On Wed, Jun 11, 2014 at 9:21 PM, Hector Santos <hsan...@isdg.net> wrote:
> > - Signature Required, Exclusive 1st party only. >>> >> >> You would simply not use DKIM-Delegate if that's your policy. >> > > Again, the fault. The policy is X, but Y is seen. The payload can be > DKIM-Delegate compliant but the actual policy is exclusive and doesn't > allow it. You need the lookup for this or prove the assertion it will > satisfy the threat analysis for this use case. No, there are two possibilities in the face of DMARC "p=reject": (1) There's no DKIM delegation, and therefore the From: domain's policy is automatically what you call first-party only. (2) There is DKIM delegation, and therefore the From: domain's policy is either first-party or authorized third-party, where the list of authorized third-parties is in the message (either DKIM-Delegate's "t=" field, or the To/Cc fields). > > "I'm ok with any trusted valid signer" > > For the trust attribute, this is where either VBR comes into play or the > DKIM_Trust_Assessment(SDID [,AUID) algorithm is applied, when its finally > available. "Any trusted valid signer" is not the same as "Any third party allowed" (which is the first thing you said). The minute you introduce the need to know if X trusts Y, you're basically back to a whitelist and scaling problems again. We really don't want (or need) to deal with this use case. We're only interested in specific third parties. > > - Signature Required, Authorized 3rd party allowed only. >>> >> >> That's the exact use case for DKIM-Delegate. >> > > Right, You want the fault of this case. In others, a domain may not expect > the DKIM-Delegate header, but that is what you see or there is no header, > and the domain expects it. It's never expected. It's used at the discretion of the From: domain to select one of two possible modes of verifying, described above. > > If DKIM-Delegate does address the above, then its becomes a good >>> optimizer. However, there still need to be an "IF ELSE" DNS lookup >>> when the DKIM-Delegate or advanced 2.0 DKIM signature is missing. >>> >> >> It only addresses one of those cases, but that's the only one we need >> to solve here. >> > > But it also has to address the others too at the same time, otherwise, > there have loop holes. I disagree, I claim those others are out of scope. We don't need them to solve this problem. > > And since one of the big benefits of this mechanism is >> that the policy becomes part of the message, there's no need to bring >> DNS (or a published whitelist of any kind) into this at all. >> > > I agree. Passing the policy via 5322 was talked about in 2005/2006 between > Jim Fenton and I. But if the signature and/or policy information in the > payload is missing, you have to do the lookup anyway. I don't agree; the policy is implicit in DMARC (if that's what you're using). > And also, how are you going to show the the payload policy actually > matches the DNS published policy? In theory, they have to be the same > because you are going to need a migration path. > In theory, DMARC would be amended to either allow for DKIM delegation always, or offer it as a flag in the DNS record. But ignoring DMARC for the moment, no additional lookup is needed here. > We can do the same with the public key, piggy-back off the 5322 payload > too, saving even more DNS calls. In theory, a compliant domain isn't going > to commit suicide by providing faulty information. By if you don't enforce > it, then it does not solve anything. > This seems to go off in the weeds a bit. Carrying the public key in the message adds a bunch of bulk to the message and then adds the requirement that the key be tied back to the domain somehow, otherwise you could use any old key and claim to be anyone. I don't think there's a need to drag DANE into this. > Overall, the problem is the DMARC verifiers are indeed enforcing the > strong policies. If you have a DKIM-Delegate to address only 3rd party > resigners, then you will need a matching backward compatible DNS version of > this. > I fail to see how DNS is a requirement for this beyond what DKIM already requires. The policy is implicit in the way the message is built with DKIM and DKIM-Delegate. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
