Skip to main content

Last Call Review of draft-faltstrom-5892bis-

Request Review of draft-faltstrom-5892bis
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-06-07
Requested 2011-05-27
Authors Patrik Fältström , Paul E. Hoffman
I-D last updated 2011-06-17
Completed reviews Secdir Last Call review of -?? by Rob Austein
Assignment Reviewer Rob Austein
State Completed
Review review-faltstrom-5892bis-secdir-lc-austein-2011-06-17
Completed 2011-06-17
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This an affirmation that the IETF has reached (rough)
consensus that an existing RFC still applies without needing any
changes.  If this sounds mad, well, welcome to IDN.

Specifically, this draft notes that, as expected, the Unicode
Consortium has updated their "Unicode Standard" specification, as they
are wont to do, and that the IETF's current algorithm (RFC 5892) for
incorporating their specification into IDN by reference appears to be
working as expected, at least for now.

The draft calls out three user-visible changes that this update to the
referenced standard will have, other than allocation of formerly
unused code points: two Vedic Sanskrit characters (U+0CF1 KANNADA SIGN
to the DISALLOWED class now map to the PVALID class, while one of the
many alternate forms of the digit one (U+19DA NEW TAI LUE THAM DIGIT
ONE) which formerly mapped to PVALID now maps to DISALLOWED.

Other than the risk of making readers' heads explode and causing
permanent brain trauma for anyone who attempts to understand this
topic, the only security issue I see here is correctly called out in
the Security Considerations section of the draft, which notes that, as
the code points in question are not likely to be used in
Internationalized Domain Names, the risk of unexpected results or
other confusion due to the change in the underlying spec is minor.

To the extent that anything involved in IDN is harmless, this draft
qualifies, so I have no security concerns about this draft as such.