It appears that Ben Schwartz <[email protected]> said: >Looks good to me.
I've spent too much time on IDNs and IDNA it it looks good to me too. Here's an unrelated request for the authors: Please change this [IANA-PSL] IANA, "IANA Managed PSL", 7 April 2026, <https://data.iana.org/TLD/tlds-alpha-by-domain.txt>. to something like this: [IANA-TLD] IANA, "IANA list of TLDs", 7 April 2026, <https://data.iana.org/TLD/tlds-alpha-by-domain.txt>. That TLD list is not even sort of a public suffix list, and the overworked volunteers who run the actual PSL would appreciate not adding extra confusion. R's, John >On Thu, Jul 23, 2026 at 12:20 PM Kaizer, Andrew ><[email protected]> wrote: >> >> > >> 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://urldefense.com/v3/__https://www.w3.org/International/articles/idn-and-iri/Overview.en*phishing__;Iw!!Bt8RZUm9aw!6bQH6nmitBR-l_XMJgu5ct-g_cY60OBIR88K4zlRRcLGzJi__uCaDd5wm5USqbgqjNNNavMlM7fUVv0vJqR4JFUM5eo$ > ><https://urldefense.com/v3/__https://www.w3.org/International/articles/idn-and-iri/Overview.en*phishing__;Iw!!Bt8RZUm9aw!6bQH6nmitBR-l_XMJgu5ct-g_cY60OBIR88K4zlRRcLGzJi__uCaDd5wm5USqbgqjNNNavMlM7fUVv0vJqR4JFUM5eo$ > >). >> 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]
