secdir review of draft-ietf-idnabis-rationale-13.txt
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Tue Oct 6 03:27:00 CEST 2009
I think what Charlie means is that there may be entries in the domain
name system that are completely binary, and that it would be
inappropriate for IDNA to prohibit such entries. I think this is okay,
because the flagged text refers to U-Labels, not binary data in general.
On 2009/10/06 5:39, Vint Cerf wrote:
> i think the point was precisely that DNSSEC should operate at DNS level
> (using only LDH-form domain names or, in IDNA2008 parlance, A-labels. No
> other form of label valid under IDNA2008 (such as a U-label) should be
> used in conjunction with DNSSEC.
> If I have not quite got that right I am sure my colleagues on
> IDNA-UPDATE with correct me.
> On Oct 5, 2009, at 4:35 PM, Charlie Kaufman wrote:
>> 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.
> Idna-update mailing list
> Idna-update at alvestrand.no
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the Idna-update