Last Call Review of draft-faltstrom-5892bis-
review-faltstrom-5892bis-secdir-lc-austein-2011-06-17-00
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 | |
Request | Last Call review on draft-faltstrom-5892bis by Security Area Directorate Assigned | |
Completed | 2011-06-17 |
review-faltstrom-5892bis-secdir-lc-austein-2011-06-17-00
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 draft...is 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 JIHVAMULIYA and U+0CF2 KANNADA SIGN UPADHMANIYA) which formerly mapped 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.