6 ms·

Time to revisit the classics from the great minds in our industry, who foresaw all these SNAFUs... Bruce Schneier, more than 20 years ago (a short read, I high

Time to revisit the classics from the great minds in our industry, who foresaw all these SNAFUs... Bruce Schneier, more than 20 years ago (a short read, I highly recommend it): Security Risks of Unicode I don’t know if anyone has considered the security implications of this. Unicode is just too complex to ever be secure. https://www.schneier.com/crypto-gram/archives/2000/0715.html https://www.schneier.com/crypto-gram/archives/2000/0715.html

bawolff 4y ago
Computers are made to do things. The most secure computer is an unpluged computer but that would be a useless computer. What is the alternative here? Not supporting non-ascii chars?
- josephcsible 4y ago
  Not supporting non-ASCII chars in domain names.
  - dezgeg 4y ago
    Perhaps good trade-off would have been that non-ASCII is allowed only in country code TLDs, with these country operators limiting to only characters in their own alphabet. E.g. for Finland .fi could do fine with just allowing ASCII + ä, ö, å.
    - burnished 4y ago
      How would that be represented on the wire? I don’t think restricting it in that way makes sense.
      - dezgeg 4y ago
        Wire format could be the same. But to prevent eg. homoglyph attacks the principle on what non-Unicode characters are allowed would be 'default deny'.
        burnished 4y ago
        Oh, of course. I retract my previous objection, brain fart on my part.
    - Symbiote 4y ago
      That is exactly what .FI and many other CCTLD registrars do: https://www.traficom.fi/en/communications/fi-domains/native-language-characters-domain-names https://www.traficom.fi/en/communications/fi-domains/native-...
      - josephcsible 4y ago
        But I don't think all of them do that. What if browsers, etc. were updated so that IDNs under TLDs where that rule isn't strictly enforced were always rendered in punycode?
        Symbiote 4y ago
        Firefox already does this, with some improvements. https://wiki.mozilla.org/IDN_Display_Algorithm https://wiki.mozilla.org/IDN_Display_Algorithm
        josephcsible 4y ago
        That's a good start, but IMO it's still too lax.
    - cryptonector 4y ago
      DNS registries are free to come up with rules like that, FYI. (And they should.)
- seri4l 4y ago
  Having a 1:1 correspondence between characters and code points would have been nice.
  - samtho 4y ago
    I think we should have at least an agreed upon subset of Unicode that squashed characters which are deemed too visually similar into singular code points, eliminating the concept of caps vs lowercase (if the language supports it), and remove any lexical control characters to get an analogue if the the “pure” hostname-style charset we enjoy in ASCII that we find in RFCs standards, for example. I’m probably naïve about this, but this is how we treat similar problems within specific applications of the ASCII charset.
    - Avamander 4y ago
      There certainly are some things that could've done better and I guess still some things we could do better avoiding past mistakes. But I have a strong bad feeling what's here already is going to remain here for the foreseaable future and the best we're gonna get is better handling rather than large changes to unicode itself.
    - bawolff 4y ago
      Well we certainly could do better, we're never be perfect on this. After all, paypa1.com is the same attack and doesn't even use unicode.
  - sterlind 4y ago
    there's valid reasons to have different code points with the same character though. like Russian с and Latin c look identical to me, but fonts might have ligatures or kerning rules that apply to one but not the other.
    - bawolff 4y ago
      Depending on how far you want to take this - 1 and l look the same on many fonts.

bawolff 4y ago

Computers are made to do things. The most secure computer is an unpluged computer but that would be a useless computer. What is the alternative here? Not supporting non-ascii chars?

josephcsible 4y ago
Not supporting non-ASCII chars in domain names.
- dezgeg 4y ago
  Perhaps good trade-off would have been that non-ASCII is allowed only in country code TLDs, with these country operators limiting to only characters in their own alphabet. E.g. for Finland .fi could do fine with just allowing ASCII + ä, ö, å.
  - burnished 4y ago
    How would that be represented on the wire? I don’t think restricting it in that way makes sense.
    - dezgeg 4y ago
      Wire format could be the same. But to prevent eg. homoglyph attacks the principle on what non-Unicode characters are allowed would be 'default deny'.
      - burnished 4y ago
        Oh, of course. I retract my previous objection, brain fart on my part.
  - Symbiote 4y ago
    That is exactly what .FI and many other CCTLD registrars do: https://www.traficom.fi/en/communications/fi-domains/native-language-characters-domain-names https://www.traficom.fi/en/communications/fi-domains/native-...
    - josephcsible 4y ago
      But I don't think all of them do that. What if browsers, etc. were updated so that IDNs under TLDs where that rule isn't strictly enforced were always rendered in punycode?
      - Symbiote 4y ago
        Firefox already does this, with some improvements. https://wiki.mozilla.org/IDN_Display_Algorithm https://wiki.mozilla.org/IDN_Display_Algorithm
        josephcsible 4y ago
        That's a good start, but IMO it's still too lax.
  - cryptonector 4y ago
    DNS registries are free to come up with rules like that, FYI. (And they should.)
seri4l 4y ago
Having a 1:1 correspondence between characters and code points would have been nice.
- samtho 4y ago
  I think we should have at least an agreed upon subset of Unicode that squashed characters which are deemed too visually similar into singular code points, eliminating the concept of caps vs lowercase (if the language supports it), and remove any lexical control characters to get an analogue if the the “pure” hostname-style charset we enjoy in ASCII that we find in RFCs standards, for example. I’m probably naïve about this, but this is how we treat similar problems within specific applications of the ASCII charset.
  - Avamander 4y ago
    There certainly are some things that could've done better and I guess still some things we could do better avoiding past mistakes. But I have a strong bad feeling what's here already is going to remain here for the foreseaable future and the best we're gonna get is better handling rather than large changes to unicode itself.
  - bawolff 4y ago
    Well we certainly could do better, we're never be perfect on this. After all, paypa1.com is the same attack and doesn't even use unicode.
- sterlind 4y ago
  there's valid reasons to have different code points with the same character though. like Russian с and Latin c look identical to me, but fonts might have ligatures or kerning rules that apply to one but not the other.
  - bawolff 4y ago
    Depending on how far you want to take this - 1 and l look the same on many fonts.