secdir review of draft-ietf-idnabis-rationale-13.txt
charliek at microsoft.com
Tue Oct 6 09:33:19 CEST 2009
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.
From: John C Klensin [mailto:klensin at jck.com]
Sent: Monday, October 05, 2009 5:17 PM
To: Charlie Kaufman; Paul Hoffman; secdir at ietf.org; iesg at ietf.org; vint at google.com; d3e3e3 at gmail.com; idna-update at alvestrand.no
Subject: RE: secdir review of draft-ietf-idnabis-rationale-13.txt
--On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman <charliek at microsoft.com> 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
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.
More information about the Idna-update