On Fri, Sep 12, 2014 at 3:16 PM, Murray S. Kucherawy
<superuser(_at_)gmail(_dot_)com>
wrote:
On Fri, Sep 12, 2014 at 10:27 AM, Doug Barton
<dougb(_at_)dougbarton(_dot_)us> wrote:
On 9/12/14 10:20 AM, Wei Chuang wrote:
I also just wanted to bring another high level idea to the table- rather
than discuss which work arounds to mandate (and all have problems), why
not revisit the authentication methods? In particular the current DKIM
method, while very powerful in the security sense, is very restrictive.
Because the large mail vendors have already spoken, and they like the way
that SPF/DKIM/DMARC work. Spending more time talking about how we think
they SHOULD work is wasted effort.
I doubt my personal view are going to change any opinions here, but if you
could put yourselves in the mindset of the engineers trying to fight
phishing attacks at large scale that were damaging the reputation of their
service you might see things differently. I wouldn't say those large
vendors like SPF/DKIM/DMARC per se and I think its rather that they were
the IETF sanctioned tools that they had at that moment to mitigate what
sounds like a nasty attack. From that perspective, having a better set of
tools that don't cause collateral damage would be pretty useful in the
future as the adversaries launching those attacks are getting more and more
sophisticated. (Again this is just my personal opinion)
What's "the current DKIM method" and how is it restrictive?
Current is just referring to RFC6376. I just describe it this way to
differentiate it because I later go onto mention
draft-kucherawy-dkim-list-canon-00 and a concept I pitched early in the
DMARC WG list which are essentially proposed improvements on DKIM.
My notion of restrictive got chopped off in the above reply snippet- but it
was: "Any changes to the signed message parts will cause the authentication
to fail. For example if a mailing lists modifies the subject or body even
if done so in some sanctioned way, it will fail DKIM.". These above two
proposed authentication methods allow for the signature verification of the
original message despite modification by some intermediate email proxy e.g.
mailing-list.
-Wei