Stéphane,
I am no expert on IDNA details or registry operations, but I want
to explain below why I think your objections to this draft are wrong.
On 14-Feb-25 21:14, Stephane Bortzmeyer wrote:
On Thu, Feb 06, 2025 at 01:32:22PM -0800,
The IESG <iesg-secretary@xxxxxxxx> wrote
a message of 38 lines which said:
The IESG has received a request from an individual submitter to consider the
following document: - 'Internationalized Domain Names in Applications (IDNA):
Registry
Restrictions and Recommendations'
<draft-klensin-idna-rfc5891bis-09.txt> as Proposed Standard
Summary: there are big problems with this draft. It should not be
published as-is.
The biggest one is the fact that it spends most time criticizing the
business model of some domain name registries than talking about
internationalized domain names (sections 1 and 4, things like "in a
zone in which the revenues are derived exclusively, or almost
exclusively, from selling or reserving (including "blocking") as many
names as possible"). IETF typically does not talk about business
models of Internet actors
That is generally true, because it is generally irrelevant, but it
is not in any sense forbidden. We do have guidelines on how to
avoid violations of anti-trust and competition law, but they certainly
do not prevent discussion of business models as such. Descriptions of
use cases are extremely common in IETF documents, and those often
amount to descriptions of business models.
(otherwise, many RFC would have to be
expanded…) and specially in derogatory terms. All these rants about
registries being for-profit or not should be removed, it is irrelevant
for IDNA.
I see no rants. I see analysis of the (presumably unintended) side
effects of cheap for-profit domain name registration, which is
entirely appropriate as background for the normative part of
the draft.
It is highly relevant to IDNA. The fact that many for-profit registrars
allocate domain names automatically, with purely mechanical checks,
for a very small fee that *by construction* excludes any possibility
of human judgment is a major enabler of confusing and deceptive domain
names. (I only have to glance at my overnight colection of spam to
see yapa70oyuckpqha.com, which is bogus and doesn't even need IDNA,
but illustrates the malign impact of cheap domain names.)
There's a comment in section 4 about when a registrar might restrict
a registration:
"(ii) there is clear evidence that the particular label would cause
harm."
Unless AI makes even more remarkable advances, this implies human
judgment, which is clearly incompatible with a world where
a registrar just offered me yapa70oyuckpqha.com for $0.01 for
the first year. I agree that section 4 is a bit discursive, but
it seems entirely reasonable as background material.
Nostalgic references to RFC 1591 are not really useful.
It isn't a question of nostalgia. It could perhaps have been stated
more explicitly that removing human judgment from the registration
process has exposed the DNS to abuse, and that IDNA makes the problem
worse.
Also, IETF RFC do not set policies for registries (for instance, this
is why RFC 954 on whois was replaced by RFC 3912) so sentences like
"actually be treated as requirements" should be deleted.
As a signatory of the MoU that handed domain name responsibility over
to ICANN, I am very conscious that the IETF doesn't set policy. To
be very precise, the MoU says:
" 4.3. Two particular assigned spaces present policy issues in addition
to the technical considerations specified by the IETF: the assignment
of domain names, and the assignment of IP address blocks. These
policy issues are outside the scope of this MOU."
Thus, the IETF *specifies the technical considerations* and the
normative part of the present draft is part of that work. It is entirely
in the IETF's scope to set such requirements and entirely correct
for the draft to underline this.
Another serious issue is that, while it refers to RFC 9499 on domain
name and DNS terminology, it creates new definitions (section 4) which
are quite vague and do not seem useful for IDNA. I've read the
beginning of section 4 with the definitions of "zones operating
primarily" and I still don't know where .fr would fit, for
instance.
I don't see any ambiguity in "Zones operating primarily or exclusively
within a organization, enterprise, or country ...".
The mention of "public domains" is specially confusing. (RFC
9499, section 9, has the proper definitions, which should be used.)
Rather, I would say, the draft should explicitly use and if necessary
extend those definitions.
And the last important problem is that it mentions vague risks ("most
dangerous and otherwise problematic cases", "obscure characters", this
last one bordering on western-centricism)
Actually, it's ASCII-centricism, and there is no avoiding it, given the
history of computing.
without a threat
analysis. Homograph attacks are as cool in security conferences (and
are a sure way to make english-speaking people laugh) as they are rare
in the wild. (Most users do not check the domain names and even if
they do, they typically don't spot the difference between
secure-bank.example and secure.bank.example; the security issue is not
in IDN.)
No, but IDN makes it worse. We can be pretty sure that if the ASCII
part of DNS becomes more resistant to domain name look-alikes, IDNA
will be exploited instead.
The [Gabrilovich2002] reference is a poor two-page document
that speaks only about theoretical possibilities, not about actual
attacks observed.
Perhaps we are lucky, and the attacks are still purely theoretical.
But I don't see that the present draft has any duty to provide a
full threat analysis; illustrative threats are enough to justify
preemptive counter-measures today.
Regards,
Brian Carpenter
To be fit for publication, sections 1 and 4 should be completely
rewritten. Section 5 is OK, it just fixes errors in previous RFC.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
