Re: [Last-Call] [EXTERNAL] Re: [secdir] Secdir last call review of draft-ietf-lamps-rfc8399bis-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>
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> 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 an
attempt to register "https://urldefense.com/v3/__http://www.**A.com__;w6E!!FJ-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-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> 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-Y8qCqXTj2!bAmAAwwM90XEQae_t77wDW-Jg2pdUWpnjlDUtR2ClbpVpgwHSLHRFzuAuoxqspZ2dbTBbF6ynCn-2rge1J1UeA$" 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
 
 

<<attachment: smime.p7s>>

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux