On 14 Feb 2025, at 12:26, Brian E Carpenter wrote:
> 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.
The business model discussion that Stéphane is objecting to are not "use cases". Note that draft-klensin-idna-rfc5891bis is an update to RFC 5891, which did not have any discussion of business models. The use cases for this draft are the same as RFC 5890 and 5891.
>
> (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.
For some of us, they are obvious.
> 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.
We strongly disagree.
> 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.)
That is unrelated to an update of the IDNA specification.
> 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.
Background for what? RFC 5890 and 5891 fine without this type of material for 15 years, why is this needed or even useful now?
>> 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.
Or better. The additions made in this draft are supported by zero evidence.
>> 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.
That MoU never discussed the requirements for registries for many good reasons. If you feel that now is a good time to start making requirements on registries that are operated by sovereign governments (all the ccTLDs), I would strongly disagree for any value of $now. Even if you do feel it is a good time to make such requirements, doing so in a document that is not, to use your euphemism, "a bit discursive".
>> 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 ...".
A person who manages such a zone does. That seems relevant to a Last Call discussion.
>
>> 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.
Please do not "extend" the definitions without agreement from the parties who worked hard to find only rough consensus on them.
>> 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.
The problems existed when we wrote RFC 5891, and it was not needed then. There was an active working group with lots of participants for RFC 5891; this draft has had only grudging review, and now an IETF Last Call.
>> 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.
Sorry to be repetitive, but how does this addition to a widely-implemented 15-year-old standard help, particularly with no evidence?
>> 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.
Such a document about threats (without good support) should not update an existing standard.
I agree with Stéphane: the thrust of this revision is actually harmful because it make unsupported recommendations to under-specified parties. A short update based only on the errata (Section 5), plus pointers to later documents (Section 6), might be useful to developers. The rest of this long-winded rant cannot be said to have IETF consensus.
--Paul Hoffman
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
