[DNSOP] Re: draft-ietf-dnsop-integration text on ASCII-or-no t

Thanks for the text. How about the following for the last paragraph:

   Displaying, normalizing, comparing, encoding, and decoding of domain
   names requires special processing, and cannot rely on generic string
   operations alone.  In the user interface, applications should take
   care to prevent potential attacks related to visually similar
   characters as described in Section 4.4 of [RFC5890].  Other security
   risks include improper use of case-sensitive comparison and failure
   to reject names whose labels contain non-preferred characters.

I would prefer to keep the references to IETF documents as possible, so RFC5890 4.4 seems most applicable. I also updated the second paragraph to state RFC1034 which has a definition for "preferred name syntax" which I did not find in RFC1123.

--Andrew Kaizer

On 7/23/26, 4:16 PM, "Ben Schwartz" <[email protected] <mailto:[email protected]>> wrote:


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 


Here's an updated proposal:


DNS integrations should be aware that the list of valid global
DNS TLDs can change, so should not hard code a list of accepted TLDs.
If applications want a list of currently valid TLDs, they can use a
routinely updated list of public suffixes such as that provided by
IANA [IANA-PSL]. Failure to account for new TLDs may lead
to inadvertent exclusion which could also lead to registrant and user
confusion.


When interacting with non-technical users, applications should present and
accept domain names in Unicode "u-label" format [RFC5890].
In the DNS wire format, applications should only use domain names that
conform to the "Preferred Name Syntax" [RFC1123] or the Attrleaf
syntax [RFC8553]. Applications should store and display names only in
fully-qualified form without the final ".", unless they also
require access to
network-local search domains [RFC3397].


Displaying, normalizing, comparing, encoding, and decoding of domain names
requires special processing, and cannot rely on generic string
operations alone.
In the user interface, applications should take care to prevent
homograph attacks
(https://www.w3.org/International/articles/idn-and-iri/Overview.en#phishing <https://www.w3.org/International/articles/idn-and-iri/Overview.en#phishing>).
Other security risks include improper use of case-sensitive comparison
and failure to reject names whose labels contain non-preferred characters.


On Tue, Jul 21, 2026 at 4:52 AM Kaizer, Andrew
<[email protected] <mailto:[email protected]>> wrote:
>
> >
> Thanks for the proposed text, Ben! Based on Andrew Sullivan's note, would the following update to the last sentence still address your point:
>
> When interacting with non-technical users, applications should
> present and accept domain names in Unicode "u-label" format
> [RFC5890]. Special care must be taken to avoid homograph attacks in
> the user interface. In the DNS wire format, applications should only
> use domain names that conform to the "Preferred Name Syntax"
> [RFC1034] or the Attrleaf syntax [RFC8553]. Domain names in wire-
> format should be checked for alignment with such syntax to avoid
> security risks and user confusion.
>
> -- Andrew Kaizer
>
> On 7/20/26, 10:28 PM, "Andrew Sullivan" <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
>
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Mon, Jul 20, 2026 at 02:45:24PM -0500, Ben Schwartz wrote:
> > Domain names in wire-format should be checked for non-compliant
> >characters (e.g.
> > labels containing ".", uppercase, whitespace, or non-ASCII characters) due to
> > security risks.
>
>
> I'd be pretty surprised to learn that labels containing uppercase characters have wire-format labels that are not compliant. The protocol documents explicitly say you're supposed to preserve the case but ignore it for matching purposes.
>
>
> A
>
>
> --
> Andrew Sullivan
> [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>
>
>
> _______________________________________________
> DNSOP mailing list -- [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>
> To unsubscribe send an email to [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>
>
>
>
> _______________________________________________
> DNSOP mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected] <mailto:[email protected]>



_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]