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