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
