Bidi Label Ordering Spoof

With NameWrapper on the horizon, there is an issue w/r/t bidi(rectional) names.

The problem occurs when you have a directionless-label before a reversed-direction label. For an LTR user, the most trivial case would be: [Directionless].[RTL].[LTR] eg."[digits].[arabic].eth".

For reference, the only characters with an explicit direction are those with bidi class "L" (LTR) or "R"/"AL" (RTL).

Consider the following labels:

  1. Directionless: "123" (Bidi class = EN)
  2. RTL: "سلمان" (Bidi class = AL)
  3. LTR: "eth" (Bidi class = L)

Consider the following names:

Under default bidi handling in most applications (eg. the web, most input fields, etc.), these names appear identical.


For input, one solution is to enforce a single bidi-direction on input. For experimentation, I’ve added a feature called Force LTR to my resolver which applies CSS override rules (direction: ltr; unicode-bidi: bidi-override) which makes these cases visually distinct but mangles the RTL case:
image

  • [1.2.3] image
  • [2.1.3] image

For display, one solution is to insert 200E (LEFT-TO-RIGHT MARK) after each label separator ("."). This enforces the label appears correctly but breaks copy-paste as 200E is disallowed by IDNA and ens-normalize.js. A partial workaround would be to allow a single 200E following each label during normalization.

A more general-but-restrictive solution would be to enforce bidi rules on the 2LD instead of the TLD (since “eth” currently hosts both RTL and LTR but itself is LTR.) If the 2LD is directionless, assume LTR. This would make the above example invalid because all subdomains of RTL 2LD would have to be RTL.


It is unclear how problematic this could be (for reference: most registered Arabic names are pure) but it enables a new class of spoofs.

4 Likes