Dave CROCKER wrote:
Ian Eiloart wrote:
Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to
display the signed header? Are there really MUA's that will display the
unsigned headers*and* assert that it was validated? If so, that's
surely a bug in the implementation of the MUA.
Your comments underscore the importance of being careful about what we
expect from DKIM. As you note, if software is DKIM-aware, it also needs
to be DKIM-intelligent.
At a deeper level, there is a continuing problem with casting DKIM as a
mechanism to "protect" a message. That's something that OpenPGP and
S/Mime do; it's not something DKIM does. DKIM merely tries to do enough
to ensure that the d= is valid, to provide a basis for reputation
assessment.
Hence, I recommend that this ISSUE be declined and closed.
Your comments underscore the importance of being careful about what
we expect from DKIM. As you note, if software is DKIM-aware, it
also needs to be DKIM-intelligent.
At a deeper level, there is a continuing problem with casting DKIM
as a mechanism to "protect" a message. That's something that
OpenPGP and S/Mime do; it's not something DKIM does. DKIM merely
tries to do enough to ensure that the d= is valid, to provide a
basis for reputation assessment.
Hence, I recommend that this ISSUE be declined and closed.
Once again, we are mixing out of scope reputation design needs that
confuses matters. This has nothing to do with reputation. In fact, it
can hurt signers if multiple 5322.From are altering scoring.
You can't pass the buck to the MTAs to validate RFC 5322 messages.
You can't pass the buck to the MUAs to enforce them to CHANGE.
While MTAs can address this now, it still needs to be noted in the
DKIM specification to help API writers add an additional DKIM
requirement to handle the special case of possible Multiple 5322.From:
DKIM binding the 5322.From is a fundamental requirement. You can not
exclude it from any implementation without violating the
specification. It is requirement to bind the 5322.From adress to the
signature and doing so it properly, is directly proportional to the
signature validity of the signer d= domain.
If there are multiple 5322.From lines, regardless of how it got there,
then there needs to be additional requirements added to 4871bis which
help implementators take this security problem into account.
This is precisely what an implementator (Alt-N) discovered and was
forced to change their software to add an "additional DKIM
requirement" to their implementation to enforce only one 5322.From
header signature binding.
What you don't want are future implementators to discovery this
"additional DKIM requirement" on their own. In fact, it can be
viewed as rather negative if this was known and it was not documented.
4871bis is active. I highly recommend to address it now with 4871bis
guidelines so that all current and future implementators can be aware
of the DKIM security problem.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html