secdir review of draft-ietf-idnabis-rationale-13.txt

[Vint Cerf]

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.

vint


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.
>
>                 --Charlie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091005/80502989/attachment-0001.htm