[ietf-dkim] Features that could be reconsidered as part of the bis process
dotis at mail-abuse.org
Thu May 21 12:06:58 PDT 2009
On May 21, 2009, at 10:43 AM, Eliot Lear wrote:
> And see my other message. I also question the value of l=. All I
> was trying to say here was that the risks are well documented and
> easily mitigated.
There are many areas beyond the scope of DKIM that might be of similar
concern. When an MUA only displays friendly-names that are signed
with a g= restricted keys, this would represent another area of concern.
DKIM results are unlikely to always provide simple answers nor will it
ensure simple annotations will be sufficient. Sorry, but DKIM is
attempting to retrofit security into highly diverse environments and
uses. There are no simple solutions.
While daily observing millions of compromised systems operating from
centralized control, the concept of being able to iteratively append
junk to the end of a phish body until it collides with a signed body
hash appears to make defeating the hash easier. Calculations of
difficulty for doing this may need to consider today's environment.
The l= parameter should make this more difficult. This has been
raised because a few have also suggested expiry is also not needed.
Having these arrows at the ready in the quiver allows a means to
respond with far less disruption than would result without these
features being available.
Are MUA vendors unable to handle the information present within
a) the DKIM signature?
b) RFC 5451 results?
If simple answers are required, use S/MIME or OpenPGP. DKIM provides
the flexibility to handle a diversity of uses and environments. Such
flexibility demands greater care when MUAs attempt to apply
annotations. And yes, these annotations may be required to indicate,
strip, or split unsigned message portions. It is too soon to tell
what features will be needed and how best they can be used. What is
clear, there are no simple answers for whether an entire message is to
be annotated or not. When a message is being signed by g= restricted
keys, even the friendly name should be excluded.
More information about the ietf-dkim