n 4/24/2014 2:27 PM, Terry Zink wrote:
ADSP was brushed off because the same folks who believed ADSP's strong
reject/discard policy concept will ever get used, also believed DMARC's strong
p=reject will never be used as well, and certainly not by the likes of a AOL.COM
and YAHOO.COM, two aged and polluted domains like millions of others who
would major interesting in improving the security quality and brand of their
domains.
Correct me if I am wrong, but I think that there are significant differences
between now and when ADSP was being investigated:
1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring it
today isn't as big an obstacle.
I don't see this as any real point to be wrong or right, but DKIM was
the direction then as well.
2. DKIM doesn't tie the d= signature field to the 5322.From: address.
This would be crux of the key philosophical debates and reason we have
the problem you today.
First, 5322.From is the only hash binding header requirement for DKIM,
so it is inherently technically impossible to untie or "separate" the
two domains.
Second, what comes first the author (original message) or the signer?
I hope you say author. :)
Third, the tie-in was built into Domainkeys which DKIM was derived
from with its own built-in expanded set of 1st and 3rd policies. ADSP
tried to reduced it to 1st party only. But since the beginning, the
original proof of DKIM concept was the AUTHOR DOMAIN POLICY layer, the
selling and marketing point. That is why POLICY was also part of the
DKIM-WG product work items, among its threat analysis and signing
practice requirements, and also DKIM architecture.
The philosophy that the two domain are separate is exactly why we have
the problem today.
So, you can DKIM-sign all you want and add authorized third party
signatures
all you want.
No you can't just blinding resign mail. Its was always a bad idea to
do so from a security and mail integration design standpoint. You
can't separate two. Again, its why you have the DMARC problem today
with list systems.
But if the From: address is different than what was authenticated, then the end
user won't understand the difference.
The goal of POLICY was to filter the obvious deterministic highly
detectable fraud. No subjective reason is required. Its persistent
and consistent. You say you do X, the receiver sees Y, there is
something wrong. Your X says to reject. The receiver honors it. If
you don't honor it, you are not compliant and are creating security
loopholes and exploits. Again, why DMARC was a problem with p=reject.
It was no surprise to anyone but those who believe that a strict
policy was a small use case -- it was proven wrong.
3. DMARC is basically an anti-phishing technology, whereas while DKIM + ADSP
can do that, it doesn't do it as well.
I don't see the difference. This is a general DKIM + POLICY issue.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
