On 4/26/11 2:03 PM, Dave CROCKER wrote:
Detecting Fake A-Label use is essential for the safe introduction of UTF-8
throughout email
DKIM does not have the task of validating input. In addition, the nature of
DKIM's crypto algorithms provides quite a bit of validity checking inherently.
This ticket is invalid.
Dave,
When DKIM allows garbage input, DKIM's output is also garbage and
untrustworthy. The saying Garbage-IN Garbage-OUT is still valid. Fake
A-Labels can still resolve resources satisfying DKIM's signing
algorithms. Cryptography only indicates some odd domain published a
public key matching the key used to sign a message. The A-Label concern
will become more apparent when UTF-8 encoding is generally permitted
within email.
Applications that simply use RFC3492 to display A-Labels could offer
highly deceptive information when Fake A-Labels have not been excluded
by the DKIM verification process. Rules imposed by RFC5890 improved
UTF-8 security significantly and should truly play a role in the DKIM
verification process.
The DKIM protocol is logically where Fake A-Labels and malformed
messages should be detected. Why give malefactors an ability to
generate deceptive and misleading information? Doing so would be evil.
Not validating input creates a bigger mess when used in conjunction with
RFC5336bis. As such, it seems unfair for the DKIM WG operating within
the Security area to close and then hand a mess over to the Applications
area EAI WG.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html