On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote:
One thing that is missing (and there's a placeholder for it) is
examples so you can see how it works. I'll make sure that's there for
-01.
Examples are good. Can we work it out here, a "software" walkthru?
Save some drafting time.
The most basic protocol fault is when no signatures, no extra new
headers are available -- the legacy operation. Here the lookup is
required. If not, the bad guy loophole is simply to remain in
legacy mode. They don't need to think about trying to find a fake
signature.
A lookup for what, and where?
The "Checking Signing Practice" (CSP) module in the DKIM architectural
overview (RFC5585), the "Sender Signing Practices Query" in the DKIM
Threat Analysis (RFC4686). In this case, DMARC.
In general, the market is finally doing a DNS lookup for policy and we
need to leverage that call for 3rd party semantics. In my view, that
is the problem we are facing.
So if the proposed DKIM-Delegate header or DKIM-Signature 2.0 tags
offer a lower overhead, shortcut to addressing all the threats, then
we need to see how that is done. I don't think it does cover the
basic use cases unless there is something else in the logic I am not
catching. More below on this.
But you're right, there's a risk of a legacy DKIM verifier getting
only the delegation signature for some reason. The exposure is
supposedly time-limited, and we're assuming verifiers all pay
attention to "x=", but it should also be documented.
Good idea to use the x= more.
Yes, the risk with the existing base DKIM verifiers, but I speak of
the more primitive, basic protocol faults "holes", "use cases" that is
central to all this:
Restrictive 1st Party (Author Domain) Signing Policies
- No Mail Expected
- Signature Required, Exclusive 1st party only.
- Signature Required, Any 3rd party allowed.
- Signature Required, Authorized 3rd party allowed only.
How will DKIM-Delegate address the above conditions?
The "No Mail" policy can be folded with the others. Previous proposals
SSP, DSAP I-D included "No Mail" policies. ADSP with a
"dkim=discardable" policy and a null public singer key. I suppose the
same can be done for DMARC "p=reject" policy and a null public signer
key. I just wanted to outline it above since it is also part of the
modern mail processing logic to check for.
The goal is to detect the faults in the above policies.
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.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
