Re: [secdir] secdir review of draft-ietf-idnabis-rationale-13.txt

[Vint Cerf <[e-mail]>]

if we mention DNSSEC at all (and perhaps it is not necessary since  
DNSSEC operates at the DNS level), we might simply say that IDNA is  
compatible with DNSSEC since signed DNS entries that reference IDNA A- 
labels are fully compatible with DNSSEC. It is a sort of gratuitous  
statement but perhaps it was requested because DNSSEC was "new" and  
the person requesting the reference wanted to be clear that IDNA  
didn't invalid the use of DNSSEC?

vint


On Oct 6, 2009, at 3:33 AM, Charlie Kaufman wrote:

> My reading of the IDNA spec was that no query response would ever  
> contain a U-label, and therefore saying that if the query response  
> did contain a U-label then DNSSEC couldn't sign or verify it seems  
> nonsensical. I believe that DNSSEC is more like part of DNS than up  
> at the layer of IDNA; it can sign anything that DNS can return.
>
> I believe the DNSSEC spec says that what is signed is the "wire  
> form" of the name, which should be unambiguous unless different wire  
> forms are used in different contexts in the DNS protocol. For DNS  
> servers following IDNA, the wire form would always be an A-label or  
> an LDH-label.
>
> I could easily believe that there are problems when DNSSEC interacts  
> with non-IDNA compliant names (either because the term "wire form"  
> was ambiguous in some contexts or because the DNSSEC spec did not  
> consistently use that terminology). But I haven't heard anyone claim  
> that yet.
>
> 	--Charlie
>
> -----Original Message-----
> From: John C Klensin [mailto:[e-mail]]
> Sent: Monday, October 05, 2009 5:17 PM
> To: Charlie Kaufman; Paul Hoffman; [e-mail]; [e-mail]; [e-mail] 
> ; [e-mail]; [e-mail]
> Subject: RE: secdir review of draft-ietf-idnabis-rationale-13.txt
>
>
>
> --On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman <[e-mail] 
> > wrote:
>
>> I considered putting in more context, but decided against it (clearly
>> a mistake).
>>
>> IDNA specifies that all internationalized domain names served by DNS
>> use the IDNA encoding, but the DNS spec does not. So the full
>> statement in the draft appears to be saying that a DNS zone that does
>> not use IDNA cannot use DNSSEC (in the sense of it wouldn't work as
>> opposed to it MUST NOT). I cannot figure out why that would be true,
>> though as I said there may be some subtlety I'm missing. I agree with
>> Andrew that I can't see why this document should mention DNSSEC at
>> all.
>
> Charlie,
>
> Thanks for the careful reading.  Let me respond as holder of the pen  
> (but one who has put a lot of stuff into the document because the WG  
> apparently wanted it rather than because I was convinced it was  
> necessary).
>
> There are at least two things going on here:
>
> (1) As a collection, the IDNA documents have a number of  
> requirements that are (or should be) stated as "if you sign up for  
> IDNA, then you are required to behave this way".  If anything  
> appears to impose requirements on DNS implementations, zones, or  
> other features except in that "conforming to IDNA"
> context, then it is unintended and almost certainly needs to be  
> fixed.  Sometimes that constraint is present in order to make sure  
> that future extensions that use a "this prefix means something  
> special" can occur without causing problems for IDNA or being  
> mutually exclusive, rather than because of an immediate
> need of IDNA as reflected in this set of documents.   However,
> it turns out to be harder to impose and describe those constraints  
> than one might expect, so some of the instances of it may be  
> convoluted.
>
> That said, IDNA cannot impose constraints on binary labels used in  
> non-IDNA-aware implementations.  It has been clear since the dawn of  
> the DNS, and certainly since RFC 2181, that arbitrary octet strings  
> are permitted to appear in zones and in queries.
> Such octet strings can certainly be UTF-8 or ISO 8859-1; they can  
> even be, e.g., UTF-16 (UCS-2) in spite of the chaos that would cause  
> for applications that assumed they could use null octets as string  
> terminators without being careful about it.
> However, whatever such labels might be, they aren't IDNA-conformant  
> IDNs or, as far as IETF Standards are concerned, IDNs at all.
>
> (2) As far as DNSSEC is concerned, you are quite correct:
> nothing in IDNA has anything to do with it.  The text is there for  
> two reasons:
>
> (i) Someone thought it important enough to mention and insisted that  
> we do so.  It wasn't me.
>
> (ii) The "two (or more) representations of the same logical label"  
> design that underlies IDNA (both the new version and the old one)  
> creates some odd ambiguities with regard to many protocols and  
> namespaces (see draft-iab-idn-encoding for an evolving discussion of  
> some of those issues).  In some cases, one pretty much has to use  
> the A-label (ACE-encoded) form.  In others, the U-label (native  
> Unicode characters) form is anticipated and required.  Still others  
> may be flexible.  When I discussed IDNABIS at a SAAG meeting some  
> time ago, I was treated to an extended discussion (during and after  
> the meeting itself) about whether certificates and other credentials  
> should keep and interpret information in ACE (A-label) form or as  
> native-character Unicode strings and about the importance of being  
> able to convert from dot-separated labels to length-label pair form  
> other than as part of calls to the DNS because some credentials were  
> kept in the latter form.  At least for a while, some of us  
> anticipated DNS servers that would accept zone files with IDNs in U- 
> label form as input and automagically do the conversion to A-labels,  
> presumably performing IDNA validation as
> part of that process.
>
> Is it desirable in that context to say "don't even think about  
> computing DNSSEC values on anything but the A-label" or "because the  
> A-label is the only thing an IDNA-conforming program can put in, or  
> look up in, a zone, DNSSEC is not affected"?  I really don't know...  
> and am certainly happy to make whatever changes in those  
> explanations that the community thinks appropriate.
>
>    john
>
>
>
>