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

JFC Morfin jefsey at
Tue Oct 6 13:04:04 CEST 2009

At 09:33 06/10/2009, 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.


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



More information about the Idna-update mailing list