Restrictive 1st Party (Author Domain) Signing Policies
- No Mail Expected
That's not in scope here. You could use draft-ietf-appsawg-nullmx for
that if you really want.
The NULLMX proposal only applies on the SMTP client, sending, callout
side. This one can be folded with the others, but again, its an
optimizer.
- 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.
- Signature Required, Any 3rd party allowed.
I don't think we're interested in that case here. Why would you want
to allow arbitrary third parties to sign on your behalf and have that
be meaningful? That would mean I can sign something that came from
you and everyone would believe you approved it.
Yes, it is a more relaxed policy that does require a signer trust and
this was the where we last left SSP because we were trying to figure
out the scaled authorized signer model. In the mean time, it helps for
the resigners to exist. But again, its the fault we are detecting.
The policy allow for any signer, but there meant be no valid
signatures. You are probably right that DKIM-Delegate can't resolve
this, but what we want is for DMARC to have the language to say:
"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.
- 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.
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.
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. 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.
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.
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.
In this vain, I think there is a lost focus on working on
dkim-delegate unless its overall functional goals comes in two
flavors; a DNS and a NON-DNS version. In this case, it is an optimizer.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
