ietf-dkim
[Top] [All Lists]

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

2009-05-21 15:10:29

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.

Agreed.

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.

-Doug

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

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