hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com
Sat Jul 26 04:08:17 CEST 2008
John C Klensin wrote:
> the UTF-8 bit doesn't seem to me to be something we need to
> discuss. There are many ways to violate any protocol, this
> among them.
A security note that it could cause havoc when TLDs allow the
registration of octet labels (non-LDH) might help. Otherwise
the bad guys could register say öko.example (UTF-8 octets)
and phish for traffic that should go to xn--ko-eka.example.
If some (maybe old) applications treat octets with a "let's
see what happens" strategy, they could arrive at the phisher.
Ditto for öko.example in legacy charsets.
[Remotely related, I just found that a whois script handling
cp 850 to UTF-8 as it should gets a windows-1252 ö for a
cp-850 ö entered on the command line, arriving at UTF-8 ÷,
and the DENIC whois informs me that ÷ko is no valid U-label.]
>> is there something about IDNA and SRV I've never heard of ?
> The fact that one can't have the protocol part(s) of an SRV
> FQDN be IDNs will, I suspect, come back to generate complaints
> at some point. I think "you can't do that" is worth saying
Got it. For the same example as above _xn--ko-eka.example is
no problem, but attempts to find the A-label for _öko are a
bad idea, xn--_ko-sna is very different from _xn--ko-eka, and
obviously not LDH, let alone a valid A-label.
> I think it is worth mentioning, even if not worth spending
> much energy one.
+1 Maybe add an example such as xn--_ko-sna vs. _xn--ko-eka.
More information about the Idna-update