Skip to main content

Last Call Review of draft-ietf-idnabis-rationale-
review-ietf-idnabis-rationale-secdir-lc-kaufman-2009-10-16-00

Request Review of draft-ietf-idnabis-rationale
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-13
Requested 2009-09-30
Authors Dr. John C. Klensin
Draft last updated 2009-10-16
Completed reviews Secdir Last Call review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-idnabis-rationale-secdir-lc-kaufman-2009-10-16
Completed 2009-10-16
review-ietf-idnabis-rationale-secdir-lc-kaufman-2009-10-16-00
I am reviewing 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. Feel free to forward to any appropriate
forum.



This I-D is part of a set of I-D’s that update the RFCs on Internationalized
Domain Names. This document is intended to become an Informational RFC and
provides a rationale for the proposed changes (as well as for the initial
design of IDNA). Its Security Considerations section defers to
draft-ietf-idnabis-defs-11.txt, which has a good Security Considerations
section.



In my opinion, the change to IDNs that warrants the most concern is the fact
that for some IDNs the new set of RFCs will specify a different representation
than the old one did. This could in theory cause security problems, though that
seems intuitively unlikely (to me, at least).



I would question one statement in the document.



From Section 8.2:



In the presence of DNSSEC, no form of a zone file or query response that
contains a U-label may be signed or the signature validated.



[a U-label indicates a name form containing non-ASCII characters not properly
encoded with IDN].



I would expect that DNSSEC would operate at the layer below IDN, and could
therefore sign and validate any data that DNS could validly return. There may
be subtle reason for this restriction that I don’t understand, but the
justification in the document didn’t seem right.



                --Charlie