ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

2009-05-20 20:29:35

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

<Prev in Thread] Current Thread [Next in Thread>