On May 20, 2009, at 2:42 PM, Murray S. Kucherawy wrote:
On Wed, 20 May 2009, Steve Atkins wrote:
Another use case is to use l= to sign a text part of an email, but
not to sign an attachment. In that case I can obviously replace the
attachment with my own content, but depending on the details of the
email structure I may well be able to replace the text section as
rendered to the user as well.
Indeed, Outlook will opt to render an HTML part over a text part
whenever given the choice. Thus, if you sign only the text/plain
portion of a message and an attacker appends a text/html part, the
unsigned HTML version will be rendered even if completely different
from the text/plain part, and DKIM would give that a thumbs-up.
Outlook gives a thumbs-up to domain MTA authorizations as the source
regardless of other domains also sending through the MTA. RFC5451
intentionally fails to provide MTA identities that could have enabled
MUAs a means to annotate questionable authorizations. It remains
fairly impractical and unsafe to rank domains based upon authorization
of widely shared MTAs under different entities' control. Many large
corporations share outbound MTAs for many reasons. Bad actors will
have little trouble defeating the facade of MTA authorization and
thereby create many victims. If Outlook does something equally as
reckless as annotating unsigned content as being signed, that
illustrates bad MUA design, not a bad protocol.
The DKIM signature is normally unseen. Those adding annotations must
be held accountable. Unlike authorization schemes, at least DKIM
indicates _exactly_ what portion of message was signed, and
specifically which domain added the signature. Those signing messages
may decide to be explicit about the length of their message. Doing
so better ensures notifications and ads that might be added by a
recipient's provider will not impair annotations of signed message
portions.
Just as DKIM currently separates the body hash from that of headers, a
header could include verification hashes for attachments as well.
This would move performing hashes over large objects to the senders
and recipients. Having the l= parameter in place enables this type of
trade-off. Large MTAs will be performing may operations of related to
verifying compliance, or perhaps doing mash-ups. The burden placed
upon these systems can be reduced by a practice of creating separate
authentication containers for attachments. There are competing
companies introducing these products today. It seems reasonable to
expect that soon this feature will find good use.
DKIM is extremely explicit about what is and is not signed. Receiving
a message where no message body is annotated as being signed should be
accompanied by a warning. DKIM would become fairly inflexible when
every feature must accommodate only one type of use. Removing DKIM
features will not ensure good MUA design. There are many issues of
equal concern not mitigated by removal of feature flexibility. If
some MUA gets it wrong, there will be other better choices available.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html