On 29 Jan 2023, at 11:19, Rob Sayre wrote: > Now, of course people are going to go make domains that don't pass IDNA2008, > but that's kind of the point, even if kind of jerky.
Hold your horses, and thanks John for including me. Now, one thing that is missing from this threat in which I have seen only a few messages, is that IDNA2008 specifically do three things: 1. Define explicitly what code points are allowed in a domain name in DNS. 2. Ensure there is a 1:1 mapping between a U-Label and A-label. 3. Stay away from any kind of definitions of mappings of series of code points that together can be used wherever something that looks like a domain name can be used. [1] is important because one bug in 2003 was the mix between what code points that can be mapped from one to another, and what code points ultimately can be used in a domain name (DNS). This has made it possible to also include the same definition for slots in other protocols, like certificates, where domain names exists. This implies it is easier in other protocols to have 1:1 mappings between the various protocol fields where they have things "that looks like domain names" and "domain names in DNS". Think about DN in X.509 certificates for example. [2] This is important as domain names might be transformed between their A-label and U-label format back and forth and having both(!) be a valid format for an according to [1] valid domain name made many protocols more stable, and specifically implementations more stable as one can have for example a domain name in a U-label format as a unicode string in a program without being afraid that conversion to an A-label format consisted on other things than a pure conversion. [3] is very important as various applications (and implementors of applications) might want and see the need to have a broader set of characters be used and displayed to the user than what is actually used in the protocol(s). The mandatory rules for mapping that IDNA2003 included, and that is included in UTS#46 is in reality too strict and there was a need for developers to be able to include context specific rules. This was not possible to implement as long as IDNA2003 was in use, but IDNA2008 did allow this, as whatever mapping rules an application wanted to use to ensure that the ultimate string used as a domain name was conformant to IDNA2008 was ok. One comment more, on whether things are "successes" or not. We have some individual code points we have identified which are ok according to IDNA2008. They can unfortunately be used as part of domain names and very very easilly be used for phishing. Simply because the same character do have multiple representations. This was something IDNA2008 was supposed to prohibit, but also the rules the registrars should put in place. To be conservative. This conservatism, when applied, protect the users on the internet against phishing campains related to corner cases which will in general never ever be visible "on the internet as a whole". Because it is not visible, is the overall solution a success? Who has the responsibility to ensure the amount of possible phishing is minimized? YMMV Last, regarding emojis...all people I have talked with regarding emojis have been kind of naive. Emojis as defined by Unicode consortium is in reality a bit more complicated than the rest of the unicode characters, and that have to do with the modifiers. Both modifiers for "skin tone" equivalents, but also modifiers that merge different emojis. For example white flag and rainbow that together create the rainbow flag emoji. This implies in turn that you can get similar, but still different, phishing attacks regarding emojis as other unicode characters unless you select a strict subset of emojis as allowed, i.e. similar process as we have for the rest of the unicode charactes in IDNA2008. Because of this, my conclusion is that what we need is not select IDNA2008 or UTS#46. We need someone to write down how a conservative software developer do use unicode characters in various places of a software, protocol etc where some text strings that can be interpreted as domain names ultimately turn into slots in the DNS protocol for lookup and responses. Such a document should build upon not only IDNA2008 and UTS#46, but also many other documents and ideas created in many different places. Best, Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
