Russ,
There is possibly one part of Mike's question that you didn't
quite answer. If so, it shows part of the problem with i18n
work: many things are obvious to those who, like yourself,
understand what is going on, but may be less so to those who
have not gotten that far. Inline below...
--On Tuesday, January 2, 2024 17:42 -0500 Russ Housley
<housley@xxxxxxxxxxxx> wrote:
>> On Jan 2, 2024, at 5:23 PM, Mike Ounsworth via Datatracker
>> <noreply@xxxxxxxx> wrote:
>>
>> Reviewer: Mike Ounsworth
>> Review result: Ready
>...
>> This is my first time contemplating internationalized domain
>> names, so this is probably more of a historical question:
>> "www.á.com" converts to the A-label "www.xn--1ca.com". Is
>> "www.xn--1ca.com" itself a valid domain name, and does that
>> introduce ambiguity that could lead to security issues?
"www.xn--1ca.com" is a valid domain name and, because
"www.á.com" can convert only to it and it can convert only to
"www.á.com", there is actually no ambiguity. The historical
issue arises because the earlier (pre-IDNA2008/ RFC 5890)
version of IDNA did not guarantee that the conversion was unique
and reversible in both directions. The importance of the
reversibility for cases much like that one was one key reason
why the new version was developed. So, if it were, say, 2006,
you would have spotted an important problem. Today, no. But
this is also one of the reasons why conformance to IDNA2008,
rather than some competing alternative, is important.
The question you didn't ask was about whether "www.á.com"
(using Unicode U+00E1 for "á") and "www.á.com" (using U+0061
("a") followed by U+0301, Combining Acute Accent) could create
any confusion. The answer is that, because IDNA2008 uses
normalization as a test, the latter combination is simply
invalid in a domain name (in IDNA2008-speak, it is not a valid
U-label). Hence, that confusion is also impossible although
some related ones might be. As Russ points out, the potential
problem is completely eliminated by sticking to A-labels in the
spec.
>> I
>> assume that this ambiguity is already sufficiently addressed
>> in one of the referenced specs, but maybe bears repeating in
>> this document's Security Considerations.
>
> Mike:
>
> 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. The strings would
> fail an exact match, but they look the same to the human.
> This is covered in RFC 5890.
>
> By always using A-labels in certificates, we are avoiding one
> source of this type of confusion. Allowing either
> "www.á.com" or "www.xn--1ca.com" required libraries to
> perform conversion before processing name constraints.
> Removing that conversion eliminates one source of security
> problems.
Exactly right.
> I would be glad to add a paragraph to the security
> considerations:
>
> The Security Consideration related to IDNA2008 in Section 4
> of [RFC5890] are relevant to this specification.
Russ, I think that would be both desirable and sufficient.
However, Mike could do all of us a favor by taking a look at the
text you point to in Section 4 with a relatively fresh set of
eyes and then telling us whether it would have answered his
question and, if not, why not. If he still sees questions or
problems, I'd be happy to collaborate on an additional sentence
or two.
best,
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
