I share the concerns I have heard raised by others. I have two
primary concerns:
1. It's not clear to me that the general approach this document takes
is the right way to address the problem at hand.
2. If we assume that the general approach is right, then this document
should clearly state what it is we expect people to do, which I do
not believe to be the case.
More detail on these below.
I agree with others that the text here seems unnecessarily and
unhelpfully negative about for-profit registrars/registry. There is a
long running and unsettled debate about the merits of low friction
mechanisms for standing up a new domain (also including free WebPKI
certificates such as those offered by Let's Encrypt), but I don't
think that the IETF should take a position on that, and this document
seems to not so subtly do so.
It's also not clear to me that all this exposition is that
helpful. Perhaps one way forward is to shrink the document
substantially to the core new clarification and normative content (the
three bullets in S 3 and the updates in S 5.1 and 5.2) and see if
there is consensus on those.
GENERAL APPROACH
As I understand the document, the problem that it is directed at is
the registration of domain names which potentially cause user
confusion about what the identity of the peer. I agree that user
confusion has been the source of real security issues, especially
but not limited to phishing.
The general theory behind this document seems to be that:
1. The use of internationalized domain names makes this problem
worse.
2. We should address this by restricting the set of domain names
which are issued, and that it should be the registrar's
responsibility to do o.
I think point (1) is also correct, but I am less convinced about
point (2).
The basic problem here is that people are extremely poorly positioned
to evaluate whether a given domain name is in fact associated with the
real-world entity they want to engage with, both because there can be
ambiguity about which domain name actually is associated with which
entity and because people are just bad at doing exact
comparisons. Consider that even in the restricted identifier space of
E.164 numbers we see phishing style attacks with plainly inappropriate
sender numbers. For instance, I got a text the other day telling me
that I needed to pay a FastTrak lane toll with a country code of +63
(the Philippines).
After years of telling people to check the domain name, the consensus
in the security community has emerged to deploy authentication systems
which do not rely upon the user checking the domain name at all.
Against this background, it seems unclear that any plausible set of
additional restrictions on domain registration will improve the
situation enough to be worthwhile.
SPECIFIC REQUIREMENTS
If we stipulate that restricting the domains which can be registered
is the right approach, and that we should require registrars/registries
to do something then IMO a standards track document needs to actually
levy specific requirement. Unfortunately, the document doesn't really
do this, but instead talks about their responsibilities under RFC 1591
(which, note, is Informational) largely tells them that they should develop
some expertise and be conservative.
The requirement of IDNA that is discussed at length elsewhere in this
specification stands: IDNA (and IDNs generally) would work better and
Internet users would be better protected and more secure if
registries and registrars (of any type) confined the labels they were
willing to accept for registration to scripts and code point
sequences that they understood thoroughly. While the IETF rarely
gives advice to those who choose to violate IETF Standards, some
advice to zones in the second category above may be in order. That
advice is that significant conservatism in what is allowed to be
registered, even for reservation purposes, and even more conservatism
about what labels are actually entered into zones and delegated, is
the best option for the Internet and its users. If practical
considerations do not allow that much conservatism, then it is
desirable to consult and utilize the many lists and tables that have
been, and continue to be, developed to advise on what might be
sensible for particular scripts and languages. Some of those lists,
tables, and recommendations are described in Section 6 below.
I am not a registrar or a registry, but this seems like it is
extremely hard to operationalize. For example, how do we know whether
a registry understands a specific script and code point sequence
"thoroughly".
By contrast, the three rules in S 3 do seem clear as do the updates
in S 5.1 and 5.2 (I have no opinion on if they are advisable).
primary concerns:
1. It's not clear to me that the general approach this document takes
is the right way to address the problem at hand.
2. If we assume that the general approach is right, then this document
should clearly state what it is we expect people to do, which I do
not believe to be the case.
More detail on these below.
I agree with others that the text here seems unnecessarily and
unhelpfully negative about for-profit registrars/registry. There is a
long running and unsettled debate about the merits of low friction
mechanisms for standing up a new domain (also including free WebPKI
certificates such as those offered by Let's Encrypt), but I don't
think that the IETF should take a position on that, and this document
seems to not so subtly do so.
It's also not clear to me that all this exposition is that
helpful. Perhaps one way forward is to shrink the document
substantially to the core new clarification and normative content (the
three bullets in S 3 and the updates in S 5.1 and 5.2) and see if
there is consensus on those.
GENERAL APPROACH
As I understand the document, the problem that it is directed at is
the registration of domain names which potentially cause user
confusion about what the identity of the peer. I agree that user
confusion has been the source of real security issues, especially
but not limited to phishing.
The general theory behind this document seems to be that:
1. The use of internationalized domain names makes this problem
worse.
2. We should address this by restricting the set of domain names
which are issued, and that it should be the registrar's
responsibility to do o.
I think point (1) is also correct, but I am less convinced about
point (2).
The basic problem here is that people are extremely poorly positioned
to evaluate whether a given domain name is in fact associated with the
real-world entity they want to engage with, both because there can be
ambiguity about which domain name actually is associated with which
entity and because people are just bad at doing exact
comparisons. Consider that even in the restricted identifier space of
E.164 numbers we see phishing style attacks with plainly inappropriate
sender numbers. For instance, I got a text the other day telling me
that I needed to pay a FastTrak lane toll with a country code of +63
(the Philippines).
After years of telling people to check the domain name, the consensus
in the security community has emerged to deploy authentication systems
which do not rely upon the user checking the domain name at all.
Against this background, it seems unclear that any plausible set of
additional restrictions on domain registration will improve the
situation enough to be worthwhile.
SPECIFIC REQUIREMENTS
If we stipulate that restricting the domains which can be registered
is the right approach, and that we should require registrars/registries
to do something then IMO a standards track document needs to actually
levy specific requirement. Unfortunately, the document doesn't really
do this, but instead talks about their responsibilities under RFC 1591
(which, note, is Informational) largely tells them that they should develop
some expertise and be conservative.
The requirement of IDNA that is discussed at length elsewhere in this
specification stands: IDNA (and IDNs generally) would work better and
Internet users would be better protected and more secure if
registries and registrars (of any type) confined the labels they were
willing to accept for registration to scripts and code point
sequences that they understood thoroughly. While the IETF rarely
gives advice to those who choose to violate IETF Standards, some
advice to zones in the second category above may be in order. That
advice is that significant conservatism in what is allowed to be
registered, even for reservation purposes, and even more conservatism
about what labels are actually entered into zones and delegated, is
the best option for the Internet and its users. If practical
considerations do not allow that much conservatism, then it is
desirable to consult and utilize the many lists and tables that have
been, and continue to be, developed to advise on what might be
sensible for particular scripts and languages. Some of those lists,
tables, and recommendations are described in Section 6 below.
I am not a registrar or a registry, but this seems like it is
extremely hard to operationalize. For example, how do we know whether
a registry understands a specific script and code point sequence
"thoroughly".
By contrast, the three rules in S 3 do seem clear as do the updates
in S 5.1 and 5.2 (I have no opinion on if they are advisable).
-Ekr
On Thu, Feb 6, 2025 at 1:38 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
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
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2025-03-03. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFCs
5890 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/
No IPR declarations have been submitted directly on this I-D.
The document contains these normative downward references.
See RFC 3967 for additional information:
rfc1591: Domain Name System Structure and Delegation (Informational - Legacy stream)
_______________________________________________
IETF-Announce mailing list -- ietf-announce@xxxxxxxx
To unsubscribe send an email to ietf-announce-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
