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

From: Charlie Kaufman <[email-masked]>
Date: Mon, 5 Oct 2009 20:35:06 +0000

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Oct 2009 16:56:40 -0400

On Mon, Oct 05, 2009 at 04:39:44PM -0400, 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.

That's exactly right.  DNSSEC operates on DNS responses, which are
required to be A-labels.  Therefore, DNSSEC is completely unaffected
by IDNA.

I think it would be a bad idea to add anything to any section,
including the security considerations section, that made any remarks
specifically about DNSSEC.  If someone really wanted to add something
about the effects of IDNA on the security of the DNS _as such_ (rather
than the use of labels as humnans understand them), I'd suggest
instead somethign to the following effect: "IDNA operates at a level
above DNS, and therefore does not affect the security of the DNS
protocols.  Security issues in the DNS protocols are also security
issues for IDNA, because IDNA depends on the DNS."  Or something like
that.  (But I don't think adding anything is a good idea.)  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Oct 2009 14:08:31 -0700

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

Note that the sentences before the one that you flagged are:

   IDNA specifies that all internationalized domain names served by DNS
   servers that cannot be represented directly in ASCII MUST use the
   A-label form.  Conversion to A-labels MUST be performed prior to a
   zone being signed by the private key for that zone.  Because of this
   ordering, it is important to recognize that DNSSEC authenticates a
   domain name containing A-labels or conventional LDH-labels, not
   U-labels. 

The sentence that you flagged is just plain confusing and can be elided without loss of value to the document.

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 5 Oct 2009 21:40:13 +0000

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 06 Oct 2009 10:27:00 +0900

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.

Regards,    Martin.

On 2009/10/06 5:39, Vint Cerf wrote:
> 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).
>>
>> 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.
>>
>> 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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Vint Cerf <[email-masked]>
Date: Mon, 5 Oct 2009 16:39:44 -0400

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.

vint

On Oct 5, 2009, at 4:35 PM, Charlie Kaufman wrote:

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Oct 2009 20:16:41 -0400

--On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman
<[email-masked]> wrote:

> 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

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Oct 2009 22:20:33 -0400

--On Tuesday, October 06, 2009 10:27 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

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

IDNA doesn't -- it applies only to IDNA-aware and -conformant
systems and name lookups which, by definition, do not involve
binary labels.

    john

---

From: Charlie Kaufman <[email-masked]>
Date: Tue, 6 Oct 2009 07:33:19 +0000

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:[email-masked]] 
Sent: Monday, October 05, 2009 5:17 PM
To: Charlie Kaufman; Paul Hoffman; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: secdir review of draft-ietf-idnabis-rationale-13.txt

--On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman <[email-masked]> wrote:

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

(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

---

From: Vint Cerf <[email-masked]>
Date: Tue, 6 Oct 2009 07:12:53 -0400

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
>
> To: Charlie Kaufman; Paul Hoffman; [email-masked]; [email-masked]; [email-masked] 
> ; [email-masked]; [email-masked]
> --On Monday, October 05, 2009 21:40 +0000 Charlie Kaufman <[email-masked] 
> > wrote:
>
> 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).
>
> 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"
> 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
> 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.
>
> (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.
>
> 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
>
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Oct 2009 09:25:55 -0400

--On Tuesday, October 06, 2009 07:12 -0400 Vint Cerf
<[email-masked]> wrote:

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

Or, if my memory is correct, the IDNA didn't require any special
handling in DNSSEC.

   john

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Oct 2009 09:33:20 -0400

> Or, if my memory is correct, the IDNA didn't require any special

This is the point, I think.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Oct 2009 09:36:43 -0400

--On Tuesday, October 06, 2009 07:33 +0000 Charlie Kaufman
<[email-masked]> 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.

Certainly it is the case that IDNA getting into trouble with
DNSSEC (or vice versa) would require at least one of 

	-- a sloppy reading of the IDNA specs
	
	-- a sloppy reading of the DNSSEC specs
	
	-- some odd case brought about by storing UTF-8 (or
	other) strings in the DNS, as discussed in
	draft-iab-idn-encoding.

Of course, we've seen sloppy readings and odd cases in
abundance, including a TLD or two that has registered strings in
ISO 8859-1, insisted that they are IDNs, and claimed national
sovereignty when criticized for that behavior.  DNSSEC would of
course work even for the latter as long as queries were in
8859-1, matching the stored form (if someone tried to make an
IDNA query to find an 8859-1 label, it would fail with or
without DNSSEC).    It seems to me that the question is whether
those cases are important enough to be worth a comment in
Rationale (not one of the normative IDNA specs, but the
non-normative explanation) and, if so, what it should say.

     john

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Oct 2009 10:03:50 -0400

>>>>> "Vint" == Vint Cerf <[email-masked]> writes:

    Vint> if we mention DNSSEC at all (and perhaps it is not necessary since
    Vint> DNSSEC operates at the DNS level), we might simply say that IDNA is
    Vint> compatible with DNSSEC since signed DNS entries that reference IDNA A- 
    Vint> labels are fully compatible with DNSSEC. It is a sort of gratuitous
    Vint> statement but perhaps it was requested because DNSSEC was "new" and
    Vint> the person requesting the reference wanted to be clear that IDNA
    Vint> didn't invalid the use of DNSSEC?
I'd be happy with either no reference to dnssec or to the sort of
statement you propose above.  I'd be happier with either than the
current text.  However in the grand scheme of things this issue is not
a huge one.

--Sam

---

From: JFC Morfin <[email-masked]>
Date: Tue, 06 Oct 2009 13:04:04 +0200

At 09:33 06/10/2009, Charlie Kaufman wrote:
>consistently use that terminology). But I haven't heard anyone claim that yet.

Charlie,

the debate over IDNA has lasted many years. During that many years 
some "WG IDNA culture" developped with its own terminology. In turn 
that terminology evolved as the consensus developped. It makes things 
more difficult to grasp for outsiders like you and us ("contributing 
users" coming from the outer world, I had to teach). Our user's point 
of view may help you figuring things out (they are discussed in 
http://tools.ietf.org/html/draft-iucg-punyplus-02). Basically we 
consider a naming pile wich includes three layers. We name them:

* UDN - as User Domain Names (in UTF), to be converted back/forth. 
This is what the user types and see.
* ADN - as Application Domain Names (in the way application wants 
them), to be converted back/forth. This is what is really used by 
non-Internet IDNA limited applications and non-internet protocols 
(hoppefully stripped from non permitted chars if they want to be 
Internet DNS interoperable)
* IDN - as Internet Domain Names (in what you call "wire form", i.e. 
strict Internet DNS names). DNSSEC fully applies on them. They result 
from the punycode encoding.

To understand why this three layer pile is the easiest want to 
understand the whole system:
- if fully respects the fundamental target to keep the DNS unaffected
- the UDN layer (therefore the unchanged DNS layer) can fully support 
any cross-technology Semantic Addressing System without the need to 
encapsualte the DNS. DNSSEC and other discussed security oriented 
possibilities are unaffected.
- user can directly type ADNs (what is named U-labels) or IDNs (what 
is named A-labels).
- security issues can be reduced to simpler layer localized considerations.

The only remaining problems are that the entire process is not end to 
end because upper-cases are not restored on the other end (what the 
punycode algorithm is now prevented to do for good reasons) and 
cannot be considered for DNS resolutions. Punyplus will address these 
two problems in a simple and robust way as an IDNA added value, once 
IDNA is published.

Best

jfc

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Oct 2009 10:44:56 -0400

--On Tuesday, October 06, 2009 10:03 -0400 Sam Hartman
<[email-masked]> wrote:

>     Vint> if we mention DNSSEC at all (and perhaps it is not
> necessary since     Vint> DNSSEC operates at the DNS level),
>...

> I'd be happy with either no reference to dnssec or to the sort
> of statement you propose above.  I'd be happier with either
> than the current text.  However in the grand scheme of things
> this issue is not a huge one.

Editor's opinion: 

People are obviously sensitive to exactly what, if anything, is
said about this.   If there is consensus that "say nothing" (or
"no reference") is an acceptable alternative, I would recommend
that we simply remove that entire subsection rather than trying
to fine-tune it.  I'm not sure that would be the right answer in
a more perfect world, but I'm concerned that we could spend a
lot of cycles trying to get things exactly right at this late
stage in document processing... or that we could make a quick
patch that we would regret later.

FWIW, if we do start rewriting, the section needs work beyond
the confusing sentence that started the discussion.  I'm not
sure that the first paragraph (which describes what DNSSEC is
about) is needed any more.   The first sentence of the second
paragraph should stress "public DNS" or something tautological
about what an "internationalized domain name" is to skirt the
draft-iab-idn-encoding issues.  

The one problem I see with removing the section entirely has to
do with the last paragraph, on which I don't think anyone has
commented.   As I assume people on the IDNA list are aware,
there are some almost-conforming DNS server products that are
heavily promoted in some parts of the world as enabling a better
quality of IDN support.  At least one variation accepts queries
in the local character set of choice, performs some orthographic
variation processing, and only then performs IDNA processing and
makes A-label-based queries to authoritative servers.  While the
ways in which they don't work have been subtle enough in
localized environments that their advocates have periodically
claimed DNS and IDNA conformance, they will certainly not work
with DNSSEC validation to the desktop because the zone will be
signed over the A-labels but the queries will be made with
U-labels or something else.   

When the initial form of that paragraph was written a year or
two ago, it seemed worthwhile to warn about that situation.
However, at this point, maybe it isn't worthwhile enough to
justify the effort to fine-tune this section.    In an ideal
world, the warning probably belongs in the DNSSEC specs, rather
than here, anyway.

    john

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Oct 2009 11:06:21 -0400

On Tue, Oct 06, 2009 at 10:44:56AM -0400, John C Klensin wrote:

> to fine-tune it.

I can support that.

> world, the warning probably belongs in the DNSSEC specs, rather

Strictly, it's not a protocol issue, but an operations issue, and
therefore ought probably to be operational advice (likely to be
reviewed in DNSOP).  I cannot believe I am getting up in public and
saying this, but if people really need that advice to be written down
somewhere I am willing to write an I-D to say it.  Especially if that
clears the issues with the current IDNA drafts.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 06 Oct 2009 11:19:47 -0400

Andrew,

I thought you were being rational up to this point.

I'll help Andrew if he decides to take the (fatal) step, and if he 
thinks it useful. It really should be a minor note, but given the level 
of confusion around IDN and DNSSEC, we may end up there anyway.

Eric

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Oct 2009 10:12:44 -0700

At 9:36 AM -0400 10/6/09, John C Klensin wrote:
>sovereignty when criticized for that behavior. 

If people are going to rely on this logic to keep (modified) wording about DNSSEC in the document, we will need to see actual cases. I strongly prefer the "remove DNSSEC from the document" option.

---

From: Elisabeth Blanconil <[email-masked]>
Date: Tue, 6 Oct 2009 17:59:50 +0200

Full agreement.

Or would we have to update IDNA each time the DNS has an extra
feature? Just to repeat that IDNA respects the DNS? That was it not
supposed to be a multilayer model?

Elisabeth Blanconil