Although DKIM is reviewed within IETF's security area, input validation by DKIM remains dangerously neglected. References of RFC5890 rather than RFC3490 and removal of the ToASCII function once again neglects proper input validation. Detecting Fake A-Label use is essential for safe introduction of UTF-8 throughout email following the imminent adoption of rfc5336bis.
RFC3490 permitted a broader range of deceptive output over RFC5890. RFC5890 also went from conditional remapping to 'reject if not right' and better restricted valid A-labels to eliminate many deceptive representations. While the intended impact of RFC5890 was to be minimal, the added restrictions improved security for UTF-8 use by detecting a broader range of Fake A-Labels and their U-Label counterpart. DKIM currently treats A-Labels as being 'assumed' valid and incorrectly relies upon resolution of DNS resources to exclude use of Fake A-Labels. Rather than assuming checks for Fake A-Labels are imposed within the DNS resolution process, this check must be explicitly defined as part of DKIM verifications. For Section 7.1.1. Validate the Signature Header Field, (below test for "i=" tag being within the "d=" tag), add: ,--- When the "d=" tag or the "i=" tag appears to contain A-Labels (prefixed with "xn--"), a test for Fake A-Labels should be made and return PERMFAIL when the A-Label is Fake. A-Labels are converted to U-Labels by removing the "xn--" prefix and following conversion rules defined in RFC3492. Per RFC5890 Section 2.3.2.1, valid labels MUST obey conversion symmetry per rules defined in RFC3492, MUST be in Unicode NFC normalized form, and MUST contain only characters defined within the RFC5890 through RFC5894 series of documents. Editor's note: Future versions of DKIM will permit use of U-Labels in addition to A-Labels after the adoption of RFC5336bis where use of RFC5890 can be assumed. It is also important that U-Labels are not permitted to resolve non-local resources (domains not within the "local" TLD). '--- Soon, domains elsewhere within email will be using UTF-8 encoding that will inhibit human comparisons against A-Label encoding expressed using the Punycode algorithm. It is not possible for users to discern on their own whether an A-Label is Fake, because even Fake A-Labels can resolve resources that may otherwise satisfy DKIM's signature validations. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
