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