On Wed, Jan 03, 2024 at 01:33:33AM +0000, Mike Ounsworth wrote:
> I’m hung up on a specific question that I don’t think is addressed by
> Security Considerations of IDNA2008 [RFC5890], but surely must be
> addressed by some DNS spec.
Yes, the IDNA RFCs and public suffix registration practices.
> My question / concern is this: let’s say that "www.xn--1ca.com" is
> already registered, has a DNS record, has certificates issued, etc.
The A-label form is the only form of the domain that you can actually
register. There is no process for registering unencoded U-label domains
under public suffixes, and no specification that leads one to interpret
some random non-ASCII label as a Unicode label, rather than binary data
in some other encoding (or just as-is).
DNS has no default "code-page" for non-ASCII labels. The only way to
represent U-labels on the wire and registry databases, ... is via the
corresponding A-label form.
Though some registries will automatically delegate the punycode
associated with closely-related domains when you register a given
domain. For example, CNNIC always assigns both the simplified and
traditional chinese names to the same registrant. So the registries
don't just blindly process random A-label forms, they apply various
rules to the associated U-labels. This is a complex topic in its
own right...
> Then I come along and register "www.á.com",
You can't meaningfully do that. No application will be doing lookups
against "www.á.com", all such names are converted to punycode prior to
lookup by any IDNA-aware application. Other applications (per e.g. RFC
1123) should reject such names as invalid hostnames, invalid email
domains, ...
One might imagine some blissfully unaware application interpreting the
UTF8-encoded string "www.á.com" as raw binary data, and making a direct
query for that name, but Verisign will never let that raw-binary form be
registered.
Such a name could be registered under a private DNS suffix, something
like "example.com" and then the hypothetical application might indeed
be able to find an A record for the raw Unicode "www.á.example.com",
without a prior conversion to A-label form, but this should not be
a security concern. Presumably, example.com does not provide a
registration service to hostile entities trying to spoof other
example.com registrants, and as noted there should be few if any
applications that accept raw binary data in hostnames.
All that said, the hypothetical problem is not entirely impossible, just
not I think a concern worth much, if any, language in the RFC text.
--
Viktor.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
