[ietf-dkim] draft-ietf-dkim-threats-03

[Douglas Otis <[e-mail]>]

The changes made to the 03 document are an improvement over the 02  
document.


There were outstanding issues excluded such as the introductory  
sentence that Jim and Eric had also raised.  The impression made at  
the Dallas meeting was the introduction used in the Base draft.  
Adopting the introduction of the current base draft provides a  
clearer statement of the DKIM mechanism.  Linking to an email-address  
is an optional extension of the DKIM mechanism.

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003077.html
----


"Affects the verification" remains a serious error.  For example, a  
compromised key does _not_ affect message verification, although a  
compromised key is listed as having a high impact.

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003078.html
----


There are packet amplifications considerations still not mentioned in  
the threat draft, such as techniques suggested on the the mailing  
list where wildcard keys might be used to facilitate message or user  
level revocation.  Other potentially hazardous techniques include  
label tree searches for parent policy records over a series of email- 
addresses.

Currently DKIM offers no technique to limit the number of  
verifications attempted per message, or the requisite number of DNS  
transactions.  The statement "a DNS-based solution to this problem  
will likely be required" suggests little appreciation of DKIM's  
possible contribution to the packet amplification problem and the  
limited solutions available.

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003076.html
----


It is still impractical to differentiate between a compromised key  
and a replay problem from the perspective of message verification  
when attempting to block abuse.  Such blocking can cause a major  
impact however.  The threat draft makes an assumption that only the  
email-address is affected, but this implies that a limited number of  
email-addresses are affected, and that the signing-domain also  
restricts use of email-addresses.  These two assumption are not valid  
for a large population of signing domains.  The verification process  
offers no clue as to what is abusive replay or what is generated from  
a compromised key.   "Affects verification" is an nonsensical basis  
for assessing impact.

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003075.html
----


An abrupt algorithm change without a dual signature transition  
invites algorithm spoofing classified as an "unknown" algorithm.   
Dealing with a worst-case scenario requires that verifiers avoid  
weaker algorithms when detecting a signature offering a superior  
algorithm had been removed.  This could be accomplished by specifying  
a signature referencing a key with a deprecation flag must be  
companied by a signature referencing a key without this flag, for  
example.

Making this situation worse, there is no assured means to verify  
whether a future key h= and k= parameters conform to a signature a=  
parameter.  Lack of specificity for future algorithm formats permits  
an algorithm spoof exploit.  This specification deficiency will be  
disruptive.  An abrupt transition provides the same status for valid  
messages as those spoofing algorithms.  This threat remains an open  
issue in both the threat as well as the base document.  Eliminating  
this threat requires only minimal specification change without  
altering the appearance of the present keys or signatures.

http://mipassoc.org/pipermail/ietf-dkim/2006q2/003074.html
----

-Doug

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