Re: [tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
I commented on the ticket but I'll do it here for completeness sake: On Sun, 31 Dec 2017 10:12:53 + nullius wrote: > I also proposed changes to permit the UTF-8 characters required for > representing names in languages other than American English, and some > other technical improvements. I added status code 5 to support > plugins which can discern when a name is in a recognized format, but > is intrinsically invalid e.g. due to checksum failure; and I expanded > the description of status code 2, for plugins which do not have TLDs > but do recognize a definite syntax. This is pointless because internationalized domain names are standardized around Punycode encoding (Unicode<->ASCII), and said standard is supported by applications that support IDN queries. I am firmly against this change, and I'm not particularly thrilled by the thought of homograph attacks either. > Given appropriate prop-279 changes, I won’t need to draw a proposal. > I’ll simply write code! It's worth keeping in mind that no one to my knowledge has implemented prop 279 in the tor code itself, though there is (IIRC) a python kludge that kind of allows development. Regards, -- Yawning Angel pgpEeie9zpgdb.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
On 2017-12-31 at 10:48:52 +, Yawning Angel wrote: This is pointless because internationalized domain names are standardized around Punycode encoding (Unicode<->ASCII), and said standard is supported by applications that support IDN queries. I am firmly against this change, and I'm not particularly thrilled by the thought of homograph attacks either. Happy New Year, Yawning; and apologies for the delayed reply. I thought I’d best work up some code for an object demonstration of why I urge the importance of UTF-8 (and also embedded spaces, which I forgot to mention explicitly). Here is an 8-word mnemonic phrase encoding for Wikileaks (http://wlupld3ptjvsgwqw.onion/), in 8 different languages or writing systems: real element glow tennis pluck museum hair shuffle 洁 爱 唱 仰 泪 吴 乎 怒 潔 愛 唱 仰 淚 吳 乎 怒 parole distance fautif sombre notoire loyal flairer ratisser retina erba idillio suonare potassio opposto india scuderia にもつ けろけろ しちりん ほめる とかす たんまつ しゃうん はんしゃ 잠자리 반죽 상품 큰딸 이불 열차 선풍기 중반 pie dulce gimnasio tabla oscuro molde guerra repetir Imagine an activist whispering this address in someone’s ear, in the people’s native tongue! Respectively, those mnemonics are in English, Chinese (Simplified), Chinese (Traditional), French, Italian, Japanese, Korean, and Spanish. Those are not my selections; they are the languages for which wordlists are currently available in the standard I am adapting. Here is a hint on how to produce these phrases: https://github.com/nym-zone/easyseed/commit/ba77be1b1a1f0c6af50ceba5c89f4adece7e5dff As for Punycode vs. UTF-8: Homograph attacks are not “solved” by Punycode any more than they would be fixed by base64ing all addresses. Punycode is not a security feature; to the contrary! CVE-2013-7424, CVE-2015-8948, CVE-2016-6261, CVE-2016-6262, CVE-2017-14062 Need I say more? With some care, I can write a perfectly secure UTF-8 handler (forbidding non-shortest form, with a proper U+FFFD replacement algorithm, etc.). Whereas I have never seen a Punycode decoder which gives me confidence in its behaviour under all possible inputs. I assiduously avoid interacting with the bloat and pitfalls of IDNA and Punycode, insofar as I can. By contrast, UTF-8 has been happily in use on Unix/Plan9 systems for a quarter-century. I know that as you say, applications which handle a string as a “domain” will Punycode it before Tor even sees it. But my thinking from the beginning was not in terms of DNS names. One of my constructive criticisms of prop-279 is that it makes that assumption. The proper question is not, “How do we make more flexible pseudo-DNS lookups?”, but rather more generally: **How can we turn the pseudorandom binary data from .onion names into forms friendlier to humans?** If the Name System API could be in some way modified to admit better answers in the long term, then it would be my pleasure to help achieve that. Now since I know that Alec Muffett is reading this thread, here are mnemonics in the same languages for facebookcorewwwi.onion: chimney capital common neither demand certain hen athlete 身 热 界 巨 置 证 假 然 身 熱 界 巨 置 證 假 然 caméra boussole chasseur mairie crayon butiner fougère annuel casuale buffone collare osare derivare capello intuito apatico かいさつ おこす かんそう ちせい ぐうせい おもたい しゅらば いはつ 노력 기획 답변 예방 매장 남자 세월 고급 calor brazo centro mover crema cabeza helio antojo Dare to dream outside the quasi-DNS box about how .onion addresses can be represented! -- null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
On Mon, 1 Jan 2018 08:45:57 + nullius wrote: > On 2017-12-31 at 10:48:52 +, Yawning Angel > wrote: > >This is pointless because internationalized domain names are > >standardized around Punycode encoding (Unicode<->ASCII), and said > >standard is supported by applications that support IDN queries. > > > >I am firmly against this change, and I'm not particularly thrilled > >by the thought of homograph attacks either. > > Happy New Year, Yawning; and apologies for the delayed reply. I > thought I’d best work up some code for an object demonstration of why > I urge the importance of UTF-8 (and also embedded spaces, which I > forgot to mention explicitly). I'm aware of the use cases for IDNs. > As for Punycode vs. UTF-8: > > Homograph attacks are not “solved” by Punycode any more than they > would be fixed by base64ing all addresses. Punycode is not a > security feature; to the contrary! CVE-2013-7424, CVE-2015-8948, > CVE-2016-6261, CVE-2016-6262, CVE-2017-14062 Need I say more? Sigh, the problem is encoding format agnostic. My point was, by allowing non-ASCII characters the onus is on *someone* to solve the problem of homograph attacks (which admittedly is a bit of a tangent). I'm painfully aware that all browsers, including Tor Browser have utterly inadequate solutions here. > I know that as you say, applications which handle a string as a > “domain” will Punycode it before Tor even sees it. But my thinking > from the beginning was not in terms of DNS names. One of my > constructive criticisms of prop-279 is that it makes that assumption. It makes that assumption because it is an entirely reasonable thing to do in the context of Tor. > Dare to dream outside the quasi-DNS box about how .onion addresses > can be represented! I will quote Alec Muffet here: > a) if Onion addresses suddenly stop looking very-similar-to DNS > addresses, Tor risks returning to a world where special expertise is > necessary to build software for it, thereby harming growth/adoption The current proposal can get "very similar-to DNS addresses" IDNs by using the same encoding format that DNS uses. Regards, -- Yawning Angel pgpy2ZSIgrhQ_.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
Yawning Angel writes: > It's worth keeping in mind that no one to my knowledge has implemented > prop 279 in the tor code itself, though there is (IIRC) a python kludge > that kind of allows development. Said kludge is here, for completeness: https://github.com/meejah/torns (It's definitely not a thing you should use "in production" or whatever, but a nice toy if you want to play with a Prop279 implementation). I'm happy to merge PRs to fix things etc but I'm not "actively developing" it. Also worth noting that Tor doesn't play nicely with multiple controllers that try to do stream-attaching; the above thing does stream-attaching. -- meejah ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
