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. > 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. --- Mike Ounsworth From: John C Klensin <john-ietf@xxxxxxx> 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) beforeseeing you two more recent ones. I'm sure that Russ can answerthese 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> "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-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-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-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-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-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-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$" ACTUALLY IS "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-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-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$" goes into the DNS as "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$" so anattempt to register "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$" again will fail, either becausethe name is already registered or because it will involve arepresentation/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-labelsare unambiguous no matter what weird things might be done withUnicode strings, strings that might not be valid U-labels. Onthe other, people, especially users, typically want DNS labelsto have mnemonic value and A-labels, especially ones involvingmuch longer strings than a single character, rarely have thatvalue and can be crazy-making.If the user sees "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$" and somehow thinks (using anotation I trust you can deduce) "www.\u0061\u0301.com" ratherthan "www.\u00E1.com" they might end up a little confused,especially if they then try to use the former in some contextthat does not do IDNA2008 checks. While that case is unlikelyto be a problem, if you wanted to take a deep dive into therathole, I could show you some that could be more difficult.Ultimately, the last paragraph of Section 4.4 of RFC 5890 isimportant but, in general and as with many other things, thereare no issues that will involve people with good intentionsworking with scripts with which they are reasonably familiar.However, someone who is malicious, who intends to createconfusion (or worse problems), and who has made the investmentto discover the edge cases can probably create cases for whichthe only remedy is to stick to A-labels and NR-LDH labelsexclusively and give up the expectation of mnemonic value.And that is why I asked the question of whether the reference toSection 4 of RFC 5890 was sufficient as well as necessary.best, john |
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
