Re: [Uta] UTS-46 / WHATWG

[Rob Sayre <[e-mail]>]

Hi,

Viktr Duhovni wrote:
[...pretty much the same stuff...]
"This document does not attempt to resolve the differences between the
conflicting specifications."

I don't think we need to say this--it's obvious.

"DNS names that conform to IDNA2008 are likely to face fewer
interoperability barriers, while applications that conform to UTS-46 may be
able to verify a broader range of certificates."

I'd be fine with adding that to the end of what I wrote, but I do want to
leave what ICANN said in the text. It seems to me that they covered the
issue pretty well.

thanks,
Rob


On Mon, Jan 30, 2023 at 11:17 AM Watson Ladd <[e-mail]> wrote:

> On Mon, Jan 30, 2023 at 10:49 AM Rob Sayre <[e-mail]> wrote:
> >
> > Hi,
> >
> > That is a reasonable thing to ask for, and I will supply edits below.
> They might sound like me rather than the authors, so I wouldn't mind if
> they write something substantially similar in their own voice.
> >
> > I also understand the point of view that says "Really all this draft
> says is 'compare A labels.'" But this is incompatible with strenuous
> objections to changes to IDNA text in the document, so I don't understand
> this behavior. When I read the document, I thought "that's not how it
> really works, and I sure wish I didn't have to read the WHATWG document to
> get the truth, because it's really long". In fact, this very mailing list
> even runs on UTS-46. See
> https://mailarchive.ietf.org/arch/msg/uta/KbtvWrG5vdW6iq0scwWpBc1xeM8/
> >
> > In Section 2, the current text is incorrect, because UTS-46 domains
> sometimes don't conform to these validity checks. So, the document is
> inconsistent in making this claim. Citing UTS-46 here would be correct,
> since that would also cover IDNA2008, but it doesn't seem like that will
> fly.
> >
> > Current:
> > ---
> > An "internationalized domain name", i.e., a DNS domain name that
> includes at least one label containing appropriately encoded Unicode code
> points outside the traditional US-ASCII range and conforming to the
> processing and validity checks specified for "IDNA2008" in [IDNA-DEFS] and
> the associated documents. In particular, it contains at least one U-label
> or A-label, but otherwise may contain any mixture of NR-LDH labels,
> A-labels, or U-labels.
> >
> > New:
> > ---
> > An "internationalized domain name", i.e., a DNS domain name that
> includes at least one label containing appropriately encoded Unicode code
> points outside the traditional US-ASCII range. In particular, it contains
> at least one U-label or A-label, but otherwise may contain any mixture of
> NR-LDH labels, A-labels, or U-labels. Refer to [[Section 7.3]] for further
> details.
> > ---
>
> I think that's right.
>
> >
> >
> > Then, in section 7.3:
> > Current:
> > ---
> > As with URIs and URLs, there are in practice at least two primary
> approaches to internationalized domain names: "IDNA2008" (see [IDNA-DEFS]
> and the associated documents) and an alternative approach specified by the
> Unicode Consortium in [UTS-46]. (At this point the transition from the
> older "IDNA2003" technology is mostly complete.) Differences in
> specification, interpretation, and deployment of these technologies can be
> relevant to Internet services that are secured through certificates (e.g.,
> some top-level domains might allow registration of names containing Unicode
> code points that typically are discouraged, either formally or otherwise).
> Although there is little that can be done by certificate matching software
> itself to mitigate these differences (aside from matching exclusively on
> A-labels), the reader needs to be aware that the handling of
> internationalized domain names is inherently complex and can lead to
> significant security vulnerabilities if not properly implemented.
> >
> > New:
> > The IETF document covering internationalized domain names is "IDNA2008"
> [IDNA-DEFS]. The Unicode Consortium publishes a similar document known as
> "UTF-46". This document allows names that are valid in IDNA2003 but not
> IDNA2008, and additionally allows characters that are not valid in either
> IETF document, such as emoji characters. This more lenient approach carries
> additional risk of semantic ambiguity and additional security
> considerations. ICANN recommends IDNA2008 [
> https://features.icann.org/ssac-advisory-use-emoji-domain-names] and
> against emoji characters in domain names. However, the internet contains
> old content published under IDNA2003, and people enjoy emoji characters, so
> consumer applications often end up using the more liberal approach in
> [UTS-46].
> > ---
>
> I think we actually need to say more here: the A-label used in the
> X509 comparison needs to be the A-label derived and used to do the DNS
> lookup. Otherwise we have the issue of bugs that change the IDN
> behavior between application and X509/TLS library breaking the
> relation between what the user put in and the cert presented.
>
> Also I don't think comparison is enough: don't name constraints need
> to be included in the calculation?
>
> Sincerely,
> Watson Ladd
>