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 rev. 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 John 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
Review completed: 2009-10-16

Review
review-ietf-idnabis-rationale-secdir-lc-kaufman-2009-10-16

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