ietf-dkim
[Top] [All Lists]

[ietf-dkim] Protecting MUAs

2010-10-18 13:13:23
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Friday, October 15, 2010 11:39 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims

So anything that circumvents "what you see is what they sent" I think
is in scope for DKIM to eliminate or mitigate.

We either believe MUAs suffer from inertia and won't in any reasonable 
timeframe be able to show the good vs. bad parts of a message, or we think this 
work can provoke such evolution.  So let's look at those two possibilities 
specifically.

If we claim MUAs will grow to embrace DKIM, then by definition they will be 
able to show the parts of the message that were covered by the signature hashes 
and those that were not.  For the double-From case, this would mean one of them 
(the "good" one) is rendered differently than the other (the "bad" one).  If 
that's the case, DKIM doesn't need to worry about it beyond providing advice 
for MUAs that they should do so because they're already going to do that.  
There's no need for normative language in this case.

If on the other hand we believe they won't change in a reasonable timeframe, 
then we appear to be asserting that is incumbent on a complete/safe/useful DKIM 
verifier to take corrective action so that the MUA's DKIM-ignorance can't be 
exploited.  That means a DKIM implementation has to be integrated into the MTA 
enough that it can cause alteration or removal of suspect header fields or even 
block message delivery entirely.  Merely detecting that an incoming message is 
malformed (e.g. two From: fields, whether or not either was signed) and 
refusing to verify it is insufficient, because that has the net effect of 
setting a bit that the MUA likely won't even check, whether that's the Boolean 
result of a library function or an Authentication-Results field that few people 
are actually seeing or checking.  So adding these enforcement requirements with 
an essentially invisible impact when errors are found adds dull teeth and 
useless complexity to the document.  Instead, this makes D!
 KIM verification a required MTA function even though we specifically said we 
were trying to create a layer that had no such capabilities (as reflected in 
RFC4871, Section 1).  That makes it bigger than what this group was ever scoped 
to do.  Maybe that means in retrospect that our scope was too small, but that's 
a different issue.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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