Bug 1439723 (fedora28-switch-to-idna2008) - Switch fedora applications to IDNA2008
Summary: Switch fedora applications to IDNA2008
Keywords:
Status: ON_QA
Alias: fedora28-switch-to-idna2008
Product: Fedora
Classification: Fedora
Component: distribution
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1449139 1098783 1439727 1449120 1449121 1449123 1449125 1449127 1449128 1449129 1449130 1449131 1449132 1449135 1449136 1449137 1449138 1449140 1449141 1449142 1449144 1449145 1449146 1449147 1449148 1449149 1449150 1449151 1452750 1577864
Blocks: 1445151
TreeView+ depends on / blocked
 
Reported: 2017-04-06 12:25 UTC by Nikos Mavrogiannopoulos
Modified: 2018-05-14 10:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Nikos Mavrogiannopoulos 2017-04-06 12:25:43 UTC
Description of problem:
Internationalized domain names exist for quite some time (IDNA2003), although the protocols describing them have evolved in an incompatible way (IDNA2008). These incompatibilities will prevent applications written for IDNA2003 to access certain problematic domain names defined with IDNA2008, e.g., faß.de is translated to domain xn--fa-hia.de with IDNA2008, while in IDNA2003 it is translated to fass.de domain. That not only causes incompatibility problems, but may be used as an attack vector to redirect users to different web sites.

The proposed change is about moving applications relying on IDNA2003, to the newer IDNA2008 standard (example: switch from libidn, which supports IDNA2003, and to libidn2 2.0.0, which supports IDNA2008). The switch should be transparent for the users.

This is part of the proposed change:
https://fedoraproject.org/wiki/Changes/IDNA2008

Comment 1 Florian Weimer 2018-01-10 14:07:34 UTC
I tried to switch glibc to libidn2, but realized that the underlying libunistring library is not thread-safe (bug 1533121).  Unfortunately, this looks like a blocker for the switch.

Comment 2 Florian Weimer 2018-03-15 16:14:51 UTC
Is the intent to use IDNA2008, IDNA2008 with TR46 processing in transitional mode, or IDNA2008 with TR46 processing in non-transitional mode?

libidn2 defaults to IDNA2008 without TR46, which is not what Firefox implements.

Comment 3 Nikos Mavrogiannopoulos 2018-03-19 06:49:27 UTC
Goal is non-transitional. Firefox implements non-transitional with transitional fallback, i.e., what is written in:
https://libidn.gitlab.io/libidn2/manual/libidn2.html#Converting-with-backwards-compatibility

(curl is also using that form)

Comment 4 Florian Weimer 2018-03-19 08:01:49 UTC
(In reply to Nikos Mavrogiannopoulos from comment #3)
> Goal is non-transitional. Firefox implements non-transitional with
> transitional fallback, i.e., what is written in:
> https://libidn.gitlab.io/libidn2/manual/libidn2.html#Converting-with-
> backwards-compatibility

I think there are three modes: IDNA2008 without TR46, IDNA2008 with TR46 in transitional mode, and IDNA2008 in non-transitional mode.

libidn2 defaults to IDNA2008 without TR46, hence my confusion.

Comment 5 Nikos Mavrogiannopoulos 2018-03-28 07:32:45 UTC
I think that's something quite unclear from documentation. I modified the function description text in the manual to be more explicit about it:
https://libidn.gitlab.io/libidn2/manual/libidn2.html#Core-Functions

"The default behavior of this function (when flags are zero) is to apply the IDNA2008 rules without the TR46 amendments. As the TR46 non-transitional processing is nowdays ubiquitous, when unsure, it is recommended to call this function with the IDN2_NONTRANSITIONAL and the IDN2_NFC_INPUT flags for compatibility with other software."

Comment 6 Florian Weimer 2018-03-28 07:43:01 UTC
(In reply to Nikos Mavrogiannopoulos from comment #5)
> I think that's something quite unclear from documentation. I modified the
> function description text in the manual to be more explicit about it:
> https://libidn.gitlab.io/libidn2/manual/libidn2.html#Core-Functions
> 
> "The default behavior of this function (when flags are zero) is to apply the
> IDNA2008 rules without the TR46 amendments. As the TR46 non-transitional
> processing is nowdays ubiquitous, when unsure, it is recommended to call
> this function with the IDN2_NONTRANSITIONAL and the IDN2_NFC_INPUT flags for
> compatibility with other software."

Thanks, but I think it's unwise to encode this policy in all the libidn2-using applications.

I mean, it's not that we haven't done this before, with crypto libraries which wouldn't disable broken algorithms and enable newer ones (and newer TLS protocols) without being explicitly told so by applications.  I'm glad we finally moved away from that model.


Note You need to log in before you can comment on or make changes to this bug.