Bug 1439723 (fedora28-switch-to-idna2008)

Summary:	Switch fedora applications to IDNA2008
Product:	[Fedora] Fedora	Reporter:	Nikos Mavrogiannopoulos <nmavrogi>
Component:	distribution	Assignee:	Václav Pavlín <vpavlin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dennis, dueno, fweimer, kevin, nmavrogi, redhat-bugzilla
Target Milestone:	---	Keywords:	Tracking
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-07-28 20:09:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1098783, 1439727, 1449120, 1449121, 1449123, 1449125, 1449127, 1449128, 1449129, 1449130, 1449131, 1449132, 1449135, 1449136, 1449137, 1449138, 1449139, 1449140, 1449141, 1449142, 1449144, 1449145, 1449146, 1449147, 1449148, 1449149, 1449150, 1449151, 1452750, 1577864
Bug Blocks:	1445151

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.