Mike, I responded to Russ's note (and your embedded question) before seeing you two more recent ones. I'm sure that Russ can answer these questions but they may be easier for me, so... --On Wednesday, January 3, 2024 01:33 +0000 Mike Ounsworth <Mike.Ounsworth=40entrust.com@xxxxxxxxxxxxxx> wrote: > Right, we're on the same wavelength. > I agree that resolving the visual ambiguity problems is > important. Good job there. > 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. > > > > My question / concern is this: let's say that > "www.xn--1ca.com" is already registered, has a DNS record, has > certificates issued, etc. Then I come along and register > "www.á.com", knowing that it is going to have an A-label > collision, and then I can get certs for "www.xn--1ca.com" > which I actually don't own. If that's a problem, then > it'll already be a problem today (ie your draft is not > introducing it. So why is that not already a problem? Is it > that "www.á.com" ACTUALLY IS "www.xn--1ca.com", so I won't > be able to register it because it's already taken? Exactly. The _only_ string that can actually be registered as "www.á.com" goes into the DNS as "www.xn--1ca.com" so an attempt to register "www.á.com" again will fail, either because the name is already registered or because it will involve a representation/coding of "á" that is not a valid U-label (i.e., not permitted at all). And... --On Wednesday, January 3, 2024 01:39 +0000 Mike Ounsworth <Mike.Ounsworth=40entrust.com@xxxxxxxxxxxxxx> wrote: > Actually, wait, hold on. >> I got into this asking similar questions. The fact that more >> than one Unicode string can produce the same visual output is >> the biggest security concern in my view. > Is that actually resolved? That means that you want the human > person at the CA to be looking at the A-label, not the > U-label, right? > > But your draft says: > " Implementations that have a user interface SHOULD > convert IDNs to Unicode for display. Specifically, > conforming implementations convert A-labels to > U-labels for display purposes. " That rule represents a tradeoff. On the one hand, only A-labels are unambiguous no matter what weird things might be done with Unicode strings, strings that might not be valid U-labels. On the other, people, especially users, typically want DNS labels to have mnemonic value and A-labels, especially ones involving much longer strings than a single character, rarely have that value and can be crazy-making. If the user sees "www.á.com" and somehow thinks (using a notation I trust you can deduce) "www.\u0061\u0301.com" rather than "www.\u00E1.com" they might end up a little confused, especially if they then try to use the former in some context that does not do IDNA2008 checks. While that case is unlikely to be a problem, if you wanted to take a deep dive into the rathole, I could show you some that could be more difficult. Ultimately, the last paragraph of Section 4.4 of RFC 5890 is important but, in general and as with many other things, there are no issues that will involve people with good intentions working with scripts with which they are reasonably familiar. However, someone who is malicious, who intends to create confusion (or worse problems), and who has made the investment to discover the edge cases can probably create cases for which the only remedy is to stick to A-labels and NR-LDH labels exclusively and give up the expectation of mnemonic value. And that is why I asked the question of whether the reference to Section 4 of RFC 5890 was sufficient as well as necessary. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
