--On Wednesday, January 3, 2024 16:23 +0000 Mike Ounsworth <Mike.Ounsworth@xxxxxxxxxxx> wrote: > Thanks John, > > [RFC5890, 4.4]: > > "On the other hand, that observation makes labels > containing characters from more than one script (often > called "mixed-script labels") even more risky -- users < will tend to see what they expect to see and context > is a powerful reinforcement to perception. > " > LOL! I love that we're straying into psychology here. Yep. But that is ultimately the problem. The oldest problem documented in the public literature of a so-called homograph issue is nothing nearly as subtle as "www.á.com", it is whether "paypal" and "раураl" are the same string. They aren't. I (or you) can make them look either identical or quite different by choice of typestyles/fonts, but, if it appeared in a domain name label, that sort of display issue is well outside the scope of LAMPS or even that of a handy web browser. >> And that is why I asked the question of whether the reference >> to >> Section 4 of RFC 5890 was sufficient as well as necessary. > Necessary, certainly. Sufficient, maybe not. > draft-ietf-lamps-rfc8399bis is really about X.509 certificates > and using Unicode tricks to fool a human CA operator into > issuing a cert that they should not. So you could probably > pull some text out of 5890 and doctor it to be specific to > certificates so that draft-ietf-lamps-rfc8399bis's Security > Considerations can be understood without doing the whole > rabbit hole dive into 589x that I've just done. > I think the salient points to bring forward are: > 1. Character confusion in Unicode is fundamentally unavoidable > (as per [RFC5890 4.4]), so any human eyeball checks performed > by the CA MUST be supplemented by machine canonical A-label > checks. > 2. I am probably exactly the target audience of this document > in that I am an expert in X.509 but not in DNS or Unicode. It > would be helpful for readers like me to include a brief > summary of the one-to-one correspondence between U-labels and > A-labels, and its implications for X.509 certificates. > Something like: For example, under these domain name > comparison rules, "www.xn--1ca.com" and "www.á.com" are in > fact the same domain name, and therefore a certificate issued > for "www.xn--1ca.com" is simultaneously also a valid > certificate for "www.á.com". Strict conformance with this > spec brings X.509 certificate processing in-line with DNS > registration and lookup behaviour in order to resolve > potential ambiguities and security issues. Additionally, while > it is outside the scope of this document, implementors of CA > software SHOULD use the same domain name comparison procedure > in all places that subscriber domain names are handled during > the vetting process. > My SecDir review is currently in Datatracker as Ready; I'm > happy for you to make some improvements to the Security > Considerations, but I'm also happy to leave my review as it > is. And that is where I sort of tune out for a bit. We are in complete agreement that something of a tutorial along those lines would be very helpful and that expecting a reader of an X.509-related spec (or any number of other specialized things) to make a deep dive into the IDNA2008 specs and even a series of specifications that they references or assume is not realistic. Whether that tutorial should be slid into this I-D is a question you, Russ, the LAMPS WG, and the SEC area are competent to answer: I am not. One alternative is to write a more general tutorial on the subject but (i) I have no idea who would write that. (ii) Even if a good draft were to appeal tomorrow, recent experience with other i19n documents causes me to believe that it would get little traction and, even if it got that far, that it would be competently reviewed and then moved efficiently through the IESG. Thinking about that stand-alone document might also provide a pragmatic answer to the "should it go into this I-D" question: if one put in enough to be _really_ helpful, there are good odds that the text would drag processing/ advancing the draft into the rathole behind it. I do think that your #1 (without expressing an opinion on whether "MUST" is appropriate) and part of #2 could be refined fairly easily into useful and largely uncontroversial text and added to the text Russ proposed. But, much beyond that, there are enraged elephants charging around the room. best, john p.s. I'm including my earlier note to you and your response as altered/ quoted by your system below. Reading through it and noticing what happened to rather simple internationalized domain names like "www.á.com" is another symptom of the problems and efforts to mitigate them... and a source of elephant-rage. > From: John C Klensin <john-ietf@xxxxxxx> > Sent: Tuesday, January 2, 2024 8:14 PM > To: Mike Ounsworth <Mike.Ounsworth@xxxxxxxxxxx>; Russ Housley > <housley@xxxxxxxxxxxx> Cc: IETF SecDir <secdir@xxxxxxxx>; > draft-ietf-lamps-rfc8399bis.all@xxxxxxxx; Last Call > <last-call@xxxxxxxx>; LAMPS <spasm@xxxxxxxx> Subject: Re: > [Last-Call] [EXTERNAL] Re: [secdir] Secdir last call review of > draft-ietf-lamps-rfc8399bis-02 > > > > 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, > > 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 > <mailto: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 >> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8q >> CqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFz >> uAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ >> <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qC >> qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzu >> AuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " is already registered, >> has a DNS record, has certificates issued, etc. Then I come >> along and register >> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8q >> CqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFz >> uAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ >> <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qC >> qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzu >> AuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$> ", knowing that it is going >> to have an A-label collision, and then I can get certs for >> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8q >> CqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFz >> uAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ >> <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qC >> qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzu >> AuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " 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 >> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8q >> CqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFz >> uAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ >> <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qC >> qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzu >> AuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " ACTUALLY IS >> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8q >> CqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFz >> uAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ >> <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qC >> qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzu >> AuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$> ", so I won't be able to >> register it because it's already taken? > > Exactly. The _only_ string that can actually be registered as > "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qC > qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuA > uoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ > <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qCq > XTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAu > oxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " goes into the DNS as > "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qC > qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuA > uoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ > <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qCq > XTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAu > oxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " so an attempt to register > "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qC > qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuA > uoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ > <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qCq > XTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAu > oxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " 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 > <mailto: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 > "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qC > qXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuA > uoxqspZ2dbTBbF6ynCn-2rge1J1UeA$ > <https://urldefense.com/v3/__http:/www.**A.com__;w6E!!FJ-Y8qCq > XTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAu > oxqspZ2dbTBbF6ynCn-2rge1J1UeA$> " and somehow thinks (using a > notation I trust you can deduce) "www.\u0061\u0301.com > <http://www./u0061/u0301.com> " rather than "www.\u00E1.com > <http://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
