secdir review of draft-ietf-idnabis-rationale-13.txt
JFC Morfin
jefsey at jefsey.com
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.
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
More information about the Idna-update
mailing list