ietf-dkim
[Top] [All Lists]

[ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // A-Label use

2011-04-25 17:20:28
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

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // A-Label use, Douglas Otis <=