[UA-discuss] Where should IDN translation happen?

Michael Casadevall michael at casadevall.pro
Tue Nov 13 19:23:41 UTC 2018


So, here is a question for the list: Where in the stack should IDN/EAI
translation happen? Should it happen in the user application, or lower
in the stack such as the core libraries that handle things like TLS
connections?

The reason I ask is that I once managed to blow up Python connecting to
a IDN website with 10 line program
(https://gist.github.com/NCommander/04e34b3fcc4af347bcfedbc053b08c06 -
with error output) trying to use the built in ssl library to connect to
an IDN website. I’ve filed a bug with Python upstream
(https://bugs.python.org/issue35234) but I think it raises a larger
question.

Python’s import ssl library is a fairly thin wrapper over OpenSSL which
is what started this investigation. During an earlier conversation on
this list, and during ICANN63, I began to have concerns about the health
of WebPKI in relation to internationalized domain names, and I spoke to
Don on investigating these issues more in-depth. As a follow up to that
conversation, I began poking OpenSSL with a stick, and found much to my
surprise, it has absolutely no support for IDN* or EAIs: See
https://gist.github.com/NCommander/d68f66f74ba0122f8bb4567ca10a6a40 for
an example

This leads library makers and applications to handle IDNs manually,
which in the case of Python, if they made a mistake can lead to the
above error, namely blowing up Python. Now, in practice, OpenSSL not
directly supporting IDNs seems to have relatively little effect on its
own. After taking a very deep dive through the RFCs, it appears that in
all relevant places, everything relating to web TLS certificates takes
EAI5Address encoding and thus requires punycode representation. However,
as I’ve just shown, there are obviously places where things have fallen
through the cracks and I think it warrants a deeper investigation.

The thing is though, and just to reiterate the question, just where in
the stack should IDN translation happen?

In the above case, had OpenSSL supported IDNs directly, it would have
prevented this bug in the first place. That being said, since TLS
essentially only uses A-labels as far as I can tell, I can’t necessarily
say it’s wrong that OpenSSL doesn’t support IDNs.  I think, though, this
is an area which, in general, that needs more attention, especially if I
can break a popular programming language with a trivial example.

Thoughts and comments welcome,
Michael


* - there is one special case for wildcards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 2468 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20181113/e6c0879a/pEpkey.asc>


More information about the UA-discuss mailing list