Subject: [dnsext] A use case

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 15 Mar 2010 12:56:05 -0400

All,

I've got to attend to CORE's Spring engineering meeting the week that
the IETF meets in Anaheim, so I don't expect to contribute much before
the Summer and Fall meetings in Holland and China. Also, I don't think
I'm necessary.

I propose that a useful use case is the SC/TC mapping problem, which
the CDNC members {.cn, .tw, .hk, .ma} operators originally proposed in
2001 to deal with by cross-registry as well as cross-script mappings.

It has the utility of being a well-known problem, affecting a very
large user population, and having known sample cases.

So, an equivalence mechanism for a label of (presentation) length 1,
in some zone, formed from a single code point in the universe of SC
and TC characters, to another, possibly distinct code point in the
same universe of SC and TC characters, in a possibly distinct zone,
extensible to labels of (presentation) length 2, ...

Things to ignore:
1. ICANN length restrictions on labels in the IANA root zone,
2. ease of existing mechanisms (which don't actually provide a
complete equivalence),
3. "exponential explosion" as a rational not to attempt an elegant
equivalence solution.

Eric

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Mar 2010 15:38:35 -0300

> the Summer and Fall meetings in Holland and China. Also, I don't think

Perhaps not necessary, but definitely helpful, in the sense of being familiar
with the underlying issue(s) and being able to help us better understand
the problem that needs to be solved.

> 3. "exponential explosion" as a rational not to attempt an elegant

I think we need some more information on the particular use case (SC/TC),
at least as far as good example cases go, and also to see if we can come
up with example solutions (or classes of solutions), before trying to generalize
those.

If we can't come up with an acceptable solution for SC/TC, further problem
definition and/or ways of scoping the particular use cases may be necessary.

First, let's see if I can paraphrase the SC/TC issue:

SC == simplified chinese
TC == traditional chinese

(And not used in the SC/TC problem itself, but there is also UH == unified han,
between japanese and korean.)

The fundamental issue is, there is no 1:1 mapping between "code
points" in SC and TC.
(A code point, if I understand it, is a "glyph", which could be a
whole word or part of a word.)

And, by extension, there is no simple mapping between words in SC and
TC, with some words
not having representations in both SC and TC.

And to further confuse things, some "glyphs" occur in identical or
near-identical forms in both SC and TC.

The problem is how does support for both TC and SC in IDN, turn into
requirements and/or mechanisms in DNS?

The component issues are TLD registration (of domain names and
corresponding delegations),
DNS lookups/answers, and management of DNS zones to which delegations
have been made.

The underlying issues are very significant:
(1) There is a need for some universally accepted "authority" on
either absolute, or context-sensitive/context-aware, word
equivalences.
(1a) Who is the authority on this expected to be?
(1b) Will this set need to change over time, or be static, or
versioned, or something else?
(1c) Will this be global, or will it itself be dependent on context
(e.g. TLD or SLD specific dictionaries)?
(2) The same equivalences need to be present for both the registration
and the look-up processes. Those are very different environments. How
can this be managed?
(3) Is it sufficient to have parallel registrations for delegations to
"identical" zones, where the same zone content (by definition) is
served by the same set of name servers?
(3a) For example, if FQDN's "foo" and "bar" are SC/TC equivalent,
without regard for size of either, or where either is registered, that
for all values "a", a.foo == a.bar, and there does not exist b where
b.foo exists and b.bar does not, nor vice versa, nor any b where b.foo
!= b.bar ==> I.E. The only differences on non-DNSSEC data between foo
and bar, are the trailing .foo and trailing .bar of any LHS values
(4) In order to contain the problem space, would it be reasonable to
place a further restriction on multi-word domain names, so that words
are properly delimited, without need for understanding the language or
context?
(4a) E.g., using some special delimiter not in the set of words or
glyphs, any instances of domain names of the form "word1word2" are
restricted to being of the form "word1<del>word2"
(4b) This would reduce the equivalence-space to just the word level,
allowing for deterministic handling of multi-word domain names IFF
there is deterministic handling of single-word equivalences

(5) Everything here would need full support in the DNSSEC space as
well. Solutions would ideally not require exponentiation of zone
signing efforts, and ideally not require any changes to the DNSSEC
spec - or at the worst, the most trivial of changes.

Comments/thoughts?

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Mar 2010 16:03:28 -0400

Dear colleagues,

> whole word or part of a word.)

If anyone really wants to explore the details of this particular
problem, I urge you very strongly to go and read the copious previous
work on the topic.  We have already a _lot_ of backgound on the
details of language issues for the communities we appear to be talking
about.  (The above has several of the details wrong, by the way.
Importantly, glyphs simply do not enter into this.)

> requirements and/or mechanisms in DNS?

Maybe.

> either absolute, or context-sensitive/context-aware, word

Absolutely not.

The thing we can do -- the only thing this WG is competent to do -- is
to work out some way by which the administrator of two different zones
can make those two zones work "the same".  What we have been trying to
understand is what "the same" means in this context -- what
compromises are acceptable -- and not what a complete solution for a
particular problem looks like.  If we do this correctly, linguistic
"variants" for this or that zone will be but one of the things for which
one can use the mechanism.

We have zero hope of coming up with a full solution to any particular
linguistic "variant" problem, partly because this WG simply doesn't
have the expertise, and partly because the problem is not
well-understood as a generic issue (because it's just not a generic
problem).

In addition, please remember that we're here to work on _protocol_,
not policy.  Discussion of universal authorities for language is well
on the other side of that divide.  

> are properly delimited, without need for understanding the language or

If you are tempted to use the term "word" in your discussion of this
topic, go back and think some more about the problem.  There are lots
of things in the DNS that aren't "words" in any dictionary.
Similarly, there are words in English, never mind any other language,
that aren't going to be usable domain names because they violate the
LDH rule.  We are not trying to solve any kind of thing having to do
with words.  It's confusing enough when people who don't understand
the DNS make this mistake: as a protocol group, we really really need
to be disciplined in our thinking and terminology on this topic.

Thanks,

A

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Mar 2010 13:52:08 -0700

> one can use the mechanism.

I whole-heartedly agree with this summary and I hope that the WG as
a whole takes it on as touchstone of whether or not work is in scope.

This mechanism should allow an administrator to make two
zones "work the same" without constant manual adjustment.  *Why*
they want to do that should remain out of scope.  Linguistic equivalence?
Numerological significance?  Humorous intent expressed in parody?  Don't care.

There may be real protocol questions raised by use cases (e.g. should the DNS
allow someone to make zone2 "work the same" as  zone1 without any action by
zone1)?  But none of those issues should vary by why someone creates an
equivalence.

The number of ratholes in the "why" question may be unbounded and I
guarantee you that some of the bigger ratholes have rodents of unusual
size.

Just two cents from,

Ted

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Mar 2010 18:35:03 -0300

Thanks for clarifying which side of the divide, the underlying problems are. ;-)

My original post was to posit that those problems exist, even if they
are Someone Else's Problem.
(Apologies to the HHGttG reference.)

And, of course, you are right, and I agree with that assessment.

> zone1)?  But none of those issues should vary by why someone creates an

Okay, so I have a protocol question, which may be in danger of
resurrecting dead horses,
just so they can be beaten:

In DNSSEC-speak, why does an RRSIG (of anything other than an DNSKEY) need
to have the FQDN of the component RRsets in the content being signed?

Once we have the SEP (secure entry point), and have validated the DNSKEY,
shouldn't the *relative* name (relative to the zone in which the owner
of the RRset/RRSIG
is to be found) be sufficient?

I ask, because if the same content is found by names "label.zone1" and
"label.zone2", and
zone1 and zone2 are, uh, zones, with unique SEP's (DS to zone1 in
zone1's parent zone,
and DS to zone2 in zone2's parent zone) which match the *same* set of
DNSKEYs, just
with unique RRsig(DNSKEY)'s, then isn't it pretty much equivalent to
have signatures
based on "label", "label.zone1", and/or "label.zone2"?

I mean "functionally equivalent", in that the same level of security
is achieved using the same
parameters and keys, just with different component junk.

If this slight variation still otherwise meets the security aspects,
it would be sufficient to have parallel
zones, and no need to add signatures beyond additional (once per zone)
SEP RRSIG(DNSKEY).

It has the added benefit that adding/removing zone "clones" has no
impact on the zone content, and
in particular, does not trigger the re-signing of a zone.

Cloning a zone boils down, in that case, to doing a new RRSIG(DNSKEY),
and creating a new DS and
publishing that in the parent zone.

Thoughts?

Brian

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 15 Mar 2010 17:41:16 -0400

Andrew,

I'm glad you replied to the interpretive response by Brian, which I
just skimmed thinking "Oh No" every few sentences.

Eric

---

From: Brian Dickson <[email-masked]>
Date: Mon, 15 Mar 2010 18:58:53 -0300

Top-reply to my own earlier message... (sorry).

The reason that relative signing of a zone, and use of DS for
"cloning" a zone works is,
because, fundamentally the "identity" of a zone is, on the authority
server, metadata which
is not explicitly found in the zone itself.

Thus, if/when the decision is made to handle RRsigs with relative
names, or some similar
mechanism that avoids duplicative signing of all records in a zone,
all that remains is to
teach implementations how to "link" differently-named zones to the
same content, and possibly
how to handle other meta-level stuff (when to trigger zone reloads,
how to handle zone transfers
of such linked zones, etc.)

And, this metadata observation means that other kinds of linkages that
might be desired, but are
otherwise impossible (linking two leafs of the same zone) can be
achieved with suitable zone cut(s)
and linking the newly created zone in multiple places (with insecure
delegations or secure delegations).

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Mar 2010 18:05:26 -0400

> just skimmed thinking "Oh No" every few sentences.

To be clear, though, I didn't mean implicitly to criticise Brian and
nobody else.  I note that Brian is wrestling with the scope of this
problem here, in public.  I think such wrestling does us a lot of
good, because in the past too many people (especially outside our
little community) have run off convinced that they have "the answer"
to "the variants problem", as though such definite articles were an
accurate picture.  It's a good thing to try things out and find them
to be blind alleys now, before we have committed to any answers.

A

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

---

From: Doug Barton <[email-masked]>
Date: Mon, 15 Mar 2010 15:12:15 -0700

On 03/15/10 13:03, Andrew Sullivan wrote:
> can make those two zones work "the same". 

I agree with most of what you said, however I am still holding out hope
that we can s/zones/labels/ here. I think zone-based solutions may be a
good start, but I would still like to see people be able to signal
equivalence for different labels _within_ a zone.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Andras Salamon <[email-masked]>
Date: Mon, 15 Mar 2010 23:15:34 +0000

>one can use the mechanism.

This is an interesting use case.  However, as far as I can tell it
was not considered when DNSSEC was designed.

I can envisage a different kind of security protocol that allows
signing equivalence classes of objects, but I'm not sure DNSSEC
can easily be adapted to this use.  Since I am no DNSSEC expert,
could someone explain in broad terms how DNSSEC would work when the
underlying objects being signed are allowed to vary?

-- Andras Salamon                   [email-masked]

---

From: John Levine <[email-masked]>
Date: 16 Mar 2010 01:52:55 -0000

>equivalence for different labels _within_ a zone.

That would be fairly essential, unless we plan to make a rule that
there's a zone cut at any point where two names are supposed to be
"the same".

It seems to me that if one can clearly state what version of "the
same" one wants, the technical choices do it are reasonably
straightforward.  For example, if it's just making zone B a copy of
zone A on a set of name servers under common management, as appears to
be desired for some new TLDs, DNAME would do.  Or if it's to make all
strings that would be read as variant spellings for the same Greek
word the same, you'd have to do it in the provisioning system, by
installing bundles for every name that has variant spellings, and
making analogous changes to applications that interpret domain names.

Has anyone tried to make a taxonomy of proposed meanings of "the
same"?  That might help us create a useful menu of responses, along
the lines of if you want this, we can do that.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Mar 2010 06:32:35 -0400

No hat.

> there's a zone cut at any point where two names are supposed to be

Right.  That's one of the possible compromises we could have to make.
I'm keen to know whether such a compromise would be acceptable.

> same"? 

See Suzanne's previous request for exactly that.  That's what we're
trying to work out just now, I think.

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Mar 2010 06:33:24 -0400

> underlying objects being signed are allowed to vary?

No.  That's part of what we're trying to invent here, alas.

A

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

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 16 Mar 2010 11:37:31 +0000

> the lines of if you want this, we can do that.

	Yes, and FWIW, here's the stage I've reached.

    Quick summary

	Equivalence (my preferred term for "sameness") may be
	implemented using replication, indirection, or any other
	means which may yet be invented.  [I think it was Ed Lewis
	who articulated the replication/indirection distinction
	succinctly.]

	The requirement for equivalence may originate from any of
	a variety of sources, including, but not restricted to 
	registrant assertion, registry offering, or regulatory 
	mandate.

	Some idea of variant strings is useful, even indispensible, 
	background (but only background) knowledge.

	Otherwise words, strings, _and labels_ are distractions.

	Only fully qualified names matter.

	A zone is a special case of an FQDN.

	Different kinds of equivalence are suggested in what follows.

    Detail

	Names:
	Only fully qualified domain names are considered.

	Equivalence is transitive (surprise!):
	If names A and B, and also B and C are pairwise equivalent, then
	so are A and C.

	Accidental Equivalence:
	Two names are accidentally equivalent if neither is the name of a 
	non-terminal node in the DNS and the same (possibly empty) set of 
	resource records is present in the DNS for each name.  This is a 
	very weak kind of equivalence, and not expected to be operationally 
	important.  For example, all names which are not found in the DNS 
	(NXDOMAIN) are accidentally equivalent.

	Concrete Equivalence:
	Two names are concretely equivalent if (after following any 
	underlying redirection chain) each is the name of a leaf node in 
	the DNS and the same non-empty set of resource records is present 
	in the DNS for each name.

	Hierarchical Equivalence:
	Two given names are hierarchically equivalent if either they are 
	concretely equivalent or all of the following conditions are met: 
	each is the name of a non-terminal node in the DNS, the same 
	(possibly empty) set of resource records is present in the DNS for 
	each name, and the name of each descendant node of either given
	name is hierarchically equivalent to the name of a single 
	corresponding descendant node of the other given name.
 
	Administrative Equivalence:
	Two names are administratively equivalent if they belong to the 
	same registrant and are hierarchically equivalent.  For example, 
	the names VIX.COM and VIXIE.SF.CA.US, as suggested in
	draft-vixie-dnsext-dnsshadow-00.html, are (or might be) 
	administratively equivalent.

	Administrative equivalence can be constructed and asserted
	by a registrant.  Administratively equivalent names need not
	have any labels in common, as Vixie's example shows.

	Formal Equivalence:
	Two names are formally equivalent if their administrative
	equivalence is contrived by a registry.  Formal equivalence
	may be mandated by policy or may be an optional service offering
	to which a registrant may subscribe.

	Formal equivalence is apparently desired for bundles of domain
	names derived from clusters of semantically equivalent IDN strings.

	Equivalent zones:
	Two zones are hierarchically, administratively, or formally 
	equivalent if the name at the apex of either zone is respectively 
	hierarchically, administratively, or formally equivalent to the 
	name at the apex of the other zone.

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 16 Mar 2010 12:25:54 +0000

> trying to work out just now, I think.

Yes. So far:

* I think there are good descriptions somewhere of the problem as it
  exists in Greek; I believe Vaggelis from the .gr registry has
  written up how and why they're "bundling" variants at the second
  level already, although I need to go back and find it.

* The most complex case I yet know of is trying to figure out what
  "the same" means for Traditional and Simplified Chinese, as
  opportunities apparently abound for context-dependent, one-to-many
  mappings at the "character" level. At least some user communities
  appear (yes, I'm hedging carefully on purpose, because all I really
  know is that I know very little) to be in a position where one can
  be considered "primary" or "canonical" with the other as a
  "variant," but some apparently can't. A great deal has been written
  in various places about this case, but I think we would also welcome
  additional enlightenment from our colleagues on this list who are
  familiar in depth with the problem.

* I have seen references to potential issues in Arabic, Hebrew, and
  Cyrillic. I hope folks living with those issues are here and willing
  to speak up, with their own descriptions or pointers to references.
  I'll of course also read private email. :)

* For a whirlwind tour of the space overall, see also the IAB plenary
  presentation in Hiroshima on internationalization of IETF protocols
  (with domain names prominently featured):
  http://www.ietf.org/proceedings/76/slides/plenaryt-1.pdf

I'll also note a couple of observations:

* Andrew has now asked us a couple of times to carefully avoid
  thinking in "words" about this, as we're here to deal with DNS
  labels. This is good advice as far as it goes, but as a friendly
  amendment I'll add that for me at least, when I start to think about
  "words" (i.e. we want string1 and string2 to match because they map
  to "the same word" in human space) it's a pretty reliable indicator
  that I've stumbled over the boundary between registry operations
  (DNS and provisioning) and policy. This may be a useful marker, as
  long as we then leave the "why" behind when we consider the "how."
  The usefulness of what we're doing has to be confined to "how," but
  "why" tells us a great deal about what policy is plausible to back
  up the technology (or not), which goes to deployability.

* Questions like whether we can require zone cuts to make certain
  semantics work are exactly what I hoped we'd be talking
  about. 

* I have no idea yet how we integrate the questions here, if at all,
  with the inverse situation of "confusing similarity," where the need
  is to prevent matches on things that should *not* compare as "the
  same."

* I see that IDNAbis is officially, per the Chair's note to the list
  yesterday, done.

thx,
Suzanne

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 16 Mar 2010 09:05:17 -0400

The big problem with signature systems is canonicalization.

You compute signatures from a bit string (usually really an octet
string) and keying material. You verify the signature by performing an
operation on the bit/octet string, signature, and some keying
material. This operation can only give you at best a binary answer.
With the usual signature/verification schemes this answer tells you
whether the signature and the verification we both done with exactly
bit-for-bit identical strings.

Since DNSSEC signs RRset, it has to and does, in effect,  specify a
canonicalization function of an RRset which produces an octet string.
The exact equality of the output of this function defines whether
superficially different RRsets (different domain name case, ordering,
whatever) are the "same" for DNSSEC purposes if you use normal
signature/verification schemes. What you are proposing could be
accomplished by changing DNSSEC canonicalization to strip out later
parts of domain names. It could also be accomplished by sort of
shifting the boundary between canonicalization and
signature/verification and using a peculiar signature/verification
algorithm that first removed part of the data. So someone right now
could design a DNSSEC signature/verification algorithm that first
pre-processed the data this way and then did a more normal
signature/verification part.

Stripping all but the first label clearly has problems. Assume I own
x.example. I have a bunch of signed RRs at foo1.a.x.example,
foo2.a.x.example, etc. If you change the canonicalization function to
strip to only the initial label, then the signatures on my real data
will also "work" for and verify then with the names smashed to
foo1.x.example, foo2.x.example, ..., as well as
foo1.randomness.a.x.example, foot2.randomness.b.x.example, etc.

I suppose if you assume that every signed zone in the universe has a
different signing key (not an unreasonable assumption if you assume
enough entropy in the keys for them to be strong), then maybe you
could strip labels above the zone apex...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Mar 2010 14:03:03 +0000

> Date: Tue, 16 Mar 2010 06:32:35 -0400
> From: Andrew Sullivan <[email-masked]>
> 

it's a new idea on me.  in-zone sameness has always just relied on CNAME,
and because it's in-zone there's an expectation that the "other names" can
be avoided as targets of NS and MX, which is the operational reason why we
might otherwise tolerate new kinds of sameness when the zone is changing.

this could be handled with in-zone (non-apex) CLONE targets, where the
primary master answers any queries for the owner of a CLONE with the RRsets
of the target of that CLONE (or an NXDOMAIN if that target does not exist.)
this would be more or less an "invisible CNAME".  or we could make act more
like an "invisible BNAME" (thus affecting children of the non-apex CLONE's
owner as well as the owner itself.)  i am *not* in favour of this since the
case for in-zone non-alias sameness is weak -- the zone owner could just
edit their content to reflect this kind of sameness.  only in the case of
sameness that crosses a zone boundary will a single zone administrator not
have such a power, and that's why i support new complexity in that area.

also note, if we go forward with this, we wouldn't have to use the same RR
(CLONE) for in-zone as for zone-crossing sameness.  however, the possibility
exists simply because CLONE as proposed only has an effect if the owner is
a zone apex.  therefore the non-apex owner encoding is available for this
purpose, if we thought architecturally that (a) this functionality was a
good idea in the first place and (b) using the same RR (that is, CLONE) would
be in some way pretty.

but, in-zone sameness should be provided as a zone administration (outboard)
function, since it does not have multiple relying parties who would have to
coordinate, as in the case of zone-crossing sameness.  (that's my opinion.)

---

From: Douglas Otis <[email-masked]>
Date: Tue, 16 Mar 2010 12:42:45 -0700

> there's a zone cut at any point where two names are supposed to be
Agreed.
> be desired for some new TLDs, DNAME would do.
With respect to new TLDs offering a solution, agreed.   However DNAME 
requires an additional label that can't be aliased.  It interferes with 
reassignment at its current location, since CNAME can not co-exist at 
the location asserting DNAME.  And DNAME only applies to name space 
above its location.  Once one understands new TLDs are required, 
facilitating zone replication appears to be the work at hand.

IDNA2003 is incompatibly updated by IDNA2008.  Of course, how can any 
update changing conversions rules remain compatible?  Is it reasonable 
to expect applications will translate queries using IDNA2008, and when 
that fails, to then try IDNA2003?  Since IDNA2003 will not go away soon, 
security and operational issues require the massive use of defensive 
name registration. :^(

The Internet is also entering an era where local proxies are provided by 
HTML5 where local name space might become a factor.  Local name space 
can be resolved using name services that use UTF-8 queries (such as 
Bonjour and LLMNR).   The concept of "same" must reflect rules applied 
against the initial name resolved.  A Naming system will not work when 
applications apply different rule-sets and obtain different results.  It 
would be far safer to have these rules applied by a consolidated name 
service.

Using name sets to capture all possible rule-set variants is both 
wasteful and dangerous.  Dangerous from the aspect of anyone knowing 
where a name takes them.  Of course, this becomes even more complex when 
results depend upon which application asked.

Perhaps another work item this WG might want to consider would be how to 
have the name service flatten the name space per rules defined by 
IDNA2008.  That way, all applications and languages are given equal 
standing.  In the end, there would be fewer moving parts, and less 
opportunity for security or operations to go wrong.

-Doug

---

From: "George Barwood" <[email-masked]>
Date: Tue, 16 Mar 2010 20:39:20 -0000

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: "John Levine" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 16, 2010 7:42 PM
Subject: Re: [dnsext] A use case

> security and operational issues require the massive use of defensive 

Shouldn't registries take steps to dis-allow registration of names that are
too similar to an already registered name?

Specifically, I would think that the registration of names that contain
upper-case characters should generally be dis-allowed, subject to appeal.
Doubtless the handling of Chinese names is more delicate.

This is getting close to legal issues, which would be off-topic here I think.

> results depend upon which application asked.

I agree. In practice users mainly use Google rather than typing domain names.
If they do type a domain name, they need to copy it carefully ( e.g. from a business card ).

It's perhaps unfortunate that upper case was ever allowed in domain names.
If this had never been the case, there would be no perceived inequality,
and various technical problems would have been avoided.

> opportunity for security or operations to go wrong.

Maybe it's too late. I don't know to what extent events have gone too far already.

---

From: "John R. Levine" <[email-masked]>
Date: 16 Mar 2010 16:46:38 -0400

> too similar to an already registered name?

That's one version of "the same" for the taxonomy.  I can imagine two 
flavors, one where all the variant versions return results, one where 
there's one that returns results and the rest are NXDOMAIN.

See "bundling".

R's,
John

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 16 Mar 2010 16:59:04 -0400

inline.

On 3/16/10 3:42 PM, Douglas Otis wrote:
> With respect to new TLDs offering a solution, agreed.

this is only one use case or class of cases. please don't assume that
this is anything more than a use case or class of cases, e.g, the .sa
IDN ccTLD FT application strings and some other as yet not offered IDN
ccTLD FT application strings.

the problem space is larger than two (or one plus three variant to be
specific to the .sa application) labels in one zone.

   However DNAME
> facilitating zone replication appears to be the work at hand.

see above.

> security and operational issues require the massive use of defensive

if you wanted to spend four, almost five of the past ten years working
the '03 and '08 issues, you should have. this isn't the place to opine
on either or their differencs, in fact, IDN is only a ... meta-class
of use cases and does not exhaust the possible utility of a general
DAG to DAG semantic equivalency mechanism more elegant than by hand
replication.

> HTML5 where local name space might become a factor.  Local name space

"might" is not yet "right".

> would be far safer to have these rules applied by a consolidated name

please no. this is just dns, not some wurlitzer of uber-meaning.

> results depend upon which application asked.

policy. not relevant.

> opportunity for security or operations to go wrong.

please, in another work group, far, far away.

-e

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 16 Mar 2010 17:08:58 -0400

On 3/16/10 4:39 PM, George Barwood wrote:
inline
...

policy. not relevant.

> Doubtless the handling of Chinese names is more delicate.

please don't guess, some know.

> This is getting close to legal issues, which would be off-topic here I think.

we really don't do "law" in the icann playpen, for the most part we do
policy within a private contract law regime, but that's also not relevant.

...

> and various technical problems would have been avoided.

case in alphabetic scripts is orthogonal to the problem. however, it
is a frequently used, imho, unfortunately used, analogy to the
problems of scripts "unified" or "simplified" or reformed or ... by
whom ever.

-e

---

From: Brian Dickson <[email-masked]>
Date: Tue, 16 Mar 2010 18:58:05 -0300

I think Nial O'Reilly's first effort at taxonomy is extremely helpful.
I'll refer to it in my comments...

>> there's a zone cut at any point where two names are supposed to be

I'm certainly open to, and in some ways hopeful that, it is possible
to do the above.

However, I think the only issue that might exist for both the "zone
proliferation" that this suggests,
and the perceived "waste" and "explosion" of parallel registrations,
comes from human effort.

If it is possible to make a well-defined set of rules, and do so in
such a way as they can be turned
into code (and thus tools), the *human* effort should be no worse than
the case for "administrative equivalence",
where a registrant registers multiple domain names (independently),
and somehow "links" them together.

(By "rules", I mean for handling the DNS side of things, where the
input is a bunch of FQDNs.
It would be up to each registry to handle the thing upstream of that,
i.e. to explode things into bundles of FQDNs.)

The instances of "formal equivalence", strictly managed and enforced
by the registry, strongly suggests
a provisioning-tool solution space, making both the enforcement, and
the mechanics of registration, as simple
in the case of a registration with only one variant, as with
registrations with N variants.

In general, I would suggest that the responsibility would lie with the
registry operators, to handle the registration,
and to produce suitable materials to the registrant to facilitate the
same level of effort for population of the registrants'
linked domains (presuming of course, that authority servers have
similarly well defined tools for handling such links.)

> reassignment at its current location, since CNAME can not co-exist at the
> location asserting DNAME.  And DNAME only applies to name space above its
> location.  Once one understands new TLDs are required, facilitating zone
> replication appears to be the work at hand.

To go back to Nial's taxonomy, observe the following:

Any "bundle" of FQDN's that are equivalent, either concretely,
formally, or administratively,
have the following properties (as a set):
- each will have a (possibly trivial) hierarchy of identical things,
call it "tree_0"
- if tree_0 is trivial, then all of the fqdn_i are "leaf" FQDNs with
no descendants
- each will have a (possibly trivial) linear hierarchy of identical things,
  i.e. a tree where each label has only one descendant, call it "tree_1",
  which occurs *above* tree_0 (i.e. to the right of tree_0 in the label squence)
- NB: tree_1 is basically a single string of labels, of length 0 or
more, of the form tree_1_k.tree_1_k-1. ... .tree_1_0
- each member of the bundle will have a unique owner FQDN, call them
fqdn_0, fqdn_1, ..., fqdn_N
- the equivalence (of the bundle members) can be administratively
asserted as occurring at any sub-label string of tree_1, prepended to
each of fqdn_i
- i.e. tree_1_f. ... tree_1_0.fqdn_i (with the set of tree_1_N's
possibly being the null set, the tree_1_N's being invariant as i
varies)
- i.e. it really doesn't matter where you decide the "unique" point
is, the rest of the observations don't change

- for sake of argument, we let the place that tree_1 is split be
arbitrary, and then we can redefine things so tree_1 is trivial:
- append the left portion of tree_1 to tree_0
- prepend the right portion of tree_1 to each fqdn_i
- note that tree_0_prime is still a tree, and still invariant, and can
still be trivial
- note that all fqdn_i_prime are still unique

All of this is to say,
(modulo making an arbitrary selection in any linear set of labels at
the RHS of the unique portions of bundles of FQDNs,)
it is always possible to make a zone cut on bundles, where the stuff
below the cut is identical (and which may be terminal RRsets).

Which is basically saying, we can do this with zone cuts alone,
as long as we can solve the DNSSEC bits to avoid having to bloat the zone
with N times as many RRSIGs, or having to "clone" the zone N times
each with unique RRSIGs.

> IDNA2003 is incompatibly updated by IDNA2008.  Of course, how can any update
> changing conversions rules remain compatible?  Is it reasonable to expect
> applications will translate queries using IDNA2008, and when that fails, to
> then try IDNA2003?  Since IDNA2003 will not go away soon, security and
> operational issues require the massive use of defensive name registration.
> :^(
>
> HTML5 where local name space might become a factor.  Local name space can be
> resolved using name services that use UTF-8 queries (such as Bonjour and
> LLMNR).   The concept of "same" must reflect rules applied against the
> initial name resolved.  A Naming system will not work when applications
> apply different rule-sets and obtain different results.  It would be far
> safer to have these rules applied by a consolidated name service.

I agree with the sentiment, but disagree with where the consolidation
needs to be done.
IMHO, the registry is the least problematic place, and if we can
provide a solution
mechanism (even if it isn't pretty or quite ideal, or has reasonable
restrictions),
that should be good enough to move towards identifying whether better solutions
exist, while not backtracking on the decision to use one of them.

As long as one of them is "good enough", we can then select the "best".

Selecting the "best" before knowing if any is good enough, is putting
the cart before the horse...

> Using name sets to capture all possible rule-set variants is both wasteful
> and dangerous.  Dangerous from the aspect of anyone knowing where a name
> takes them.  Of course, this becomes even more complex when results depend
> upon which application asked.

I think "wasteful" is in the eye of the beholder. If the "waste" is
theoretical and/or from
the perspective of elegance, it might not really matter. If what is
wasted is human effort
in, for example, the provisioning of variants, then yes, we want to be
sure we don't create
waste if we can come up with ways to avoid it.

However, *if* it is deemed feasible to have tools instantiate
("explode") the variants
that occur within a registry, there would be, by definition, no
addition human effort
at the level of the registrant, and thus no "waste" per se.

> have the name service flatten the name space per rules defined by IDNA2008.
>  That way, all applications and languages are given equal standing.  In the
> end, there would be fewer moving parts, and less opportunity for security or
> operations to go wrong.

I'll leave it to others to discuss this, but it looks to me like that
would be heading
in the wrong direction -- presuming that it is feasible and is the
group consensus,
to have registry-managed automatic provisioning/registration of variant bundles.

In the case where such bundles (of potentially large, but still
finite, variants) exist,
and are linked at both the registry  and the authority server to the
same "set of things",
then the need to flatten things at the query side is mooted, and the
problem goes away.
(Or at least, it is no longer a DNS problem per se.)

Brian

---

From: Douglas Otis <[email-masked]>
Date: Tue, 16 Mar 2010 15:49:19 -0700

> ccTLD FT application strings.
Reference to TLDs was to clarify ready solutions for flattening the name 
space requires additional zones.
> specific to the .sa application) labels in one zone.
This was never suggested.
> DAG to DAG semantic equivalency mechanism more elegant than by hand
Disagree.  At IDNA2008 deployment is when security becomes affected.  
Security and requisite support were poorly addressed.  Don't describe a 
means to resolve Directed Acyclic Graphs as some other compelling reason 
for altering DNS.  DNS is not about encoding language heuristics.  The 
concern for the WG is to ensure the function of name resolutions.  The 
exigent situation created by IDNA2008 is its incompatibilities with 
IDNA2003.  No name encoding change can be compatible, however this work 
neglected transitional methodologies, and have therefore created a 
problem for DNS.
>> The Internet is also entering an era where local proxies are provided
Yet...
> please no. this is just dns, not some wurlitzer of uber-meaning
>    
Strictly from a security aspect, results of other name resolution 
services are often indiscernible by applications.
>> results depend upon which application asked.
This is a security problem that affects DNS nonetheless.
> please, in another work group, far, far away.
Flattening the name space per IDNA2008 _by the server_ would cause the 
least confusion and ensure all applications operate consistently.  
Although such an option would not be immediate, it would eventually 
allow name space consolidation, and allow a reduction of servers and 
service latency.  Perhaps such a change would consume a status bit, or 
perhaps an extension option.  Any domain name server change would be 
work done within this WG.

-Doug

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 16 Mar 2010 19:38:02 -0400

inline.

On 3/16/10 6:49 PM, Douglas Otis wrote:
> Security and requisite support were poorly addressed.

I don't know why you missed WGLC but you still have the opportunity to
make your case for defects in the IDNA2008 documents. Please do so
there rather than here.

  Don't describe a
> neglected transitional methodologies, and have therefore created a

I've no idea what this means.

> work done within this WG.

I seem to have missed the discussion of flattened name spaces in the
IDNAbis WG, but there were a few bits of mail I missed over the past
two years.

I'm happy to let you continue with whatever it is that you do.

Eric

---

From: Douglas Otis <[email-masked]>
Date: Tue, 16 Mar 2010 18:00:21 -0700

On 3/16/10 2:58 PM, Brian Dickson wrote:
>  I think Nial O'Reilly's first effort at taxonomy is extremely
>  helpful. I'll refer to it in my comments...

>  input is a bunch of FQDNs. It would be up to each registry to handle
>  the thing upstream of that, i.e. to explode things into bundles of
>  FQDNs.)

People will be confronted with a disarray of names which may or may not 
resolve a web page, depending upon the application or OS used and 
whether resource expenditures were made by the name bundle.  The 
resulting uncertainty will likely benefit phishers who will quickly take 
up any slack. :^(

>  by the registry, strongly suggests a provisioning-tool solution
>  space, making both the enforcement, and the mechanics of
>  registration, as simple in the case of a registration with only one
>  variant, as with registrations with N variants.

Since most want to have the set of names function as one, this will 
incur additional fees for name registrations, certificates, and 
rule-sets needed at firewalls, MTAs and other services.  In the short 
term, this will require additional resources beyond the norm.

>  In general, I would suggest that the responsibility would lie with
>  the registry operators, to handle the registration, and to produce
>  suitable materials to the registrant to facilitate the same level of
>  effort for population of the registrants' linked domains (presuming
>  of course, that authority servers have similarly well defined tools
>  for handling such links.)

While this can be done at a price, eventually less resource intensive 
solutions become possible.

> > With respect to new TLDs offering a solution, agreed.   However
> > DNAME requires an additional label that can't be aliased.  It
> > interferes with reassignment at its current location, since CNAME
> > can not co-exist at the location asserting DNAME.  And DNAME only
> > applies to name space above its location.  Once one understands
> > new TLDs are required, facilitating zone replication appears to be
> > the work at hand.
[...]
>  All of this is to say, (modulo making an arbitrary selection in any
>  linear set of labels at the RHS of the unique portions of bundles of
>  FQDNs,) it is always possible to make a zone cut on bundles, where
>  the stuff below the cut is identical (and which may be terminal
>  RRsets).
>
>  Which is basically saying, we can do this with zone cuts alone, as
>  long as we can solve the DNSSEC bits to avoid having to bloat the
>  zone with N times as many RRSIGs, or having to "clone" the zone N
>  times each with unique RRSIGs.

Two problems:
1) DNS will not directly support much of the desired aliasing.
2) DNSSEC also does not support signatures for multiple names.

Meta-information placed into a zone can facilitate cloning to automate 
the bundle of FQDNs.  That could be accomplished quickly.

> > The Internet is also entering an era where local proxies are
> > provided by HTML5 where local name space might become a factor.
> > Local name space can be resolved using name services that use
> > UTF-8 queries (such as Bonjour and LLMNR).   The concept of "same"
> > must reflect rules applied against the initial name resolved.  A
> > Naming system will not work when applications apply different
> > rule-sets and obtain different results.  It would be far safer to
> > have these rules applied by a consolidated name service.
>
>  needs to be done. IMHO, the registry is the least problematic place,
>  and if we can provide a solution mechanism (even if it isn't pretty
>  or quite ideal, or has reasonable restrictions), that should be good
>  enough to move towards identifying whether better solutions exist,
>  while not backtracking on the decision to use one of them.
>

There are at least two concurrent ways to address IDNA2003 to IDNA2008 
incompatibilities.  Using a resource intensive approach of zone cloning 
via meta info offers protections in the short term.  A long term 
solution would be to have IDNA2008 consolidations become a function of 
the name server itself, and thereby deprecate most of the name bundles 
independent of whether IDNA2008 had been adopted and the applications 
upgraded.

-Doug

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Mar 2010 01:25:22 -0300

(Following up my own post again, to continue developing the concept in
the open to avoid blind alleys...)

> with N times as many RRSIGs, or having to "clone" the zone N times

So, from looking at 4034/4034/5155 et al, having RRSIGs over the same RRsets,
when those sets are resolved via different FQDNs (via parallel
bundles), validated,
seems to come down to three ways forward:

(1) duplicate the zone content and regenerate the RRSIGs with a new signer
   per bundle instance, or combine all the RRSIGs in a multi-signed zone
   (so no DNSSEC changes are needed, but does not scale at all well)
(2) modify the "signer" and "owner"  definitions in the signature
methodology used, in 4034/4035
   (to remove the fqdn_i trailing component from the signer and owner names)
or
(3) modify the validation methodology used without changing the
"signer" and "owner",
   so that RRSIGs from one "signer" and "owner" can be used for validating
   all authenticated secure delegations to the "same" zone "bundle".

In case (2), we are not stripping *all* trailing labels off, we are
*only* trimming off an identical
set of trailing labels from all owners' FQDNs.

E.g. if we have the same zone known as "foo.example.com", and also as
"foo.bar.example.com";
and within the zone we have "a.b.c" and "a.d", then the following
FQDN's can all be resolved:
a.b.c.foo.example.com
a.b.c.foo.bar.example.com (identical bundle element to previous FQDN)
a.d.foo.example.com
a.d.foo.bar.example.com (identical bundle element to previous FQDN)

When doing RRSIGs, we would take the FQDNs above, and remove any
instance of any parent
secure entry point "owner", i.e. foo.example.com or foo.bar.example.com.

This would leave us with "owner" labels "a.b.c", and "a.d". We would
not be causing collisions
between the two different "a" labels, because their location inside
the zone is still uniquely identified.

Still, the number of DNSSEC RFC's that would need to be modified is
non-trivial, as would be the case
for code on servers, resolvers, and authenticators.

In case (3), the RRSIGs would be the same, but the validation process
would be slightly more complex.

The presumption is that a subset of RRSIGs (compared to what is
currently required) would exist, representing
a subset of the "parent" "bundle" zones. The subset may be of size 1,
or perhaps more than 1 if the zone operator
chooses (e.g. for operational redundancy).

If the Signer's Name from the RRSIG matches the last N labels of the
owner of the RRSIG, it's the same as now, no changes.

If the Signer's Name does not match the last N labels, we need to do
some extra work to validate the signature.

The presumption at this point is, that we have authenticated the
delegation into this zone (DS and RRSIG(DS)).
The SEP (secure entry point) is a DNSKEY used to sign the zone, even
if the zone was signed with a different Signer (aka owner).

First, we need to use the Signer Name, and authenticate the delegation
chain down to the SEP using this name.
We need to find the *same* DNSKEY at the secure entry point, signed by
this (new) Signer Name.
If the two DNSKEYs are not identical, validation fails (bogus or
insecure, not sure which.)

Next, we need to verify that the same relative owner, under the Signer
Name's zone, returns the same RRSET and RRSIG RDATA.
In other words, that looking up <label-string>.fqdn_1 returns the same
RRSET as <label-string>.fqdn_2, where fqdn_2 is the Signer Name found
on the original RRSIG.

And finally, the reconstructed signature data, once signed, matches
the signature in the RRSIG, or else validation fails.

In our example case, if the Signer Name on all the RRSIGs is
foo.bar.example.com, and we are trying to validate
a.d.foo.example.com, then:
(1) We already have had to validate the SEP for foo.example.com, and
have its authenticated DNSKEY
(2) We now need to validate the SEP for foo.bar.example.com
(3) And we need to look up the same qtype as our original query, for
a.d.foo.bar.example.com,
(4) And finally, if the RRsets match and the RRSIGs match, we attempt
to validate a.d.foo.bar.example.com.
If it validates, we have validated a.d.foo.example.com too (and return
the appropriate result).

If the same RRset, covered by the same RRSIG (but with the wrong
Signer Name), is validated with the same DNSKEY, the presumption is
that the absence of an RRSIG with the right Signer Name is no less
secure.

The claim is, a matching (i.e. identical RDATA) set of authenticated
DNSKEYs, means a signature validated by any one of those DNSKEYs is
equally valid, and proves the validity under all the (identical)
DNSKEYs.
Identical DNSKEYs validated by different DS records, is how the
location/identity of the zone itself achieves it's relative
"portability".
If we trust the authentication mechanism in use for DNSSEC, then
extending it in this manner does not fundamentally weaken the trust
model.

I prefer the "cleanness" of Case 2, since it doesn't fundamentally
change the authentication process, only the signature process.
However, there are fewer moving parts of the DNSSEC spec that get
changed in Case 3 -- even if those are the more delicate parts of the
process.
I recognize that it may be somewhat easier to get consensus to make
changes if those changes are fewer and more distinct, which seems to
be the properties of Case 3.

I have donned my nomex underwear, just in case.... :-)

Brian