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

[John C Klensin]

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