On 11/13/2016 1:50 AM, Murray S. Kucherawy wrote:> I've posted a draft
that attempts to address an attack that's begun to
appear with DKIM. Interestingly, we called it out as a possible
attack in RFC6376 and even RFC4871, but now it's apparently happening
and being annoying enough that people (I believe from the MAAWG
community) are asking if there's a protocol solution that's possible.
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
Thanks for the write up. I'm just now reading this (a quick review)
and I have several points to make about this effort:
From what I read so far, this is 1::MANY distribution issue and less
of a 1::1 direct, private email path issue but the 1::1 path is being
exploited to prepare a 1::many distribution at some systems?
Not excluding another possible tech solutions/proposals to close this
"security loophole," the code changes required are significant, both
at the signer and verify. With integrated systems, passing the
distribution list to the signer is required. There is much change to
be considered.
If it promotes code changes, then we should consider other DKIM
related situations as well to be included in what is essentially an
DKIM Update. For example, John's double signature proposal can be
considere, and in addition, we could also review the "i=" AUID
identity to see if it can help. Our package can the i= for list
distributions.
But this here bothers me:
9. Implementation Status
The next release of OpenDKIM will implement this proposal. OpenDKIM
is in widespread use, including at very large installations, so use
and utility of this extension can be easily observed.
Since this is a security loophole, I'm concern that this proposal
needs a very thorough review, including reviewing other proposals and
solutions. You could be jumping the gun to implement something that
will be harder to pull back and once again, the IETF needs to remember
that not everyone uses OpenDKIM.
Thanks for your consideration
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html