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 (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. Nostalgic references to RFC 1591 are not really useful.
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.
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. The mention of "public domains" is specially confusing. (RFC
9499, section 9, has the proper definitions, which should be used.)
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) 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.) The [Gabrilovich2002] reference is a poor two-page document
that speaks only about theoretical possibilities, not about actual
attacks observed.
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
