<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8">Hi,</div><div><br></div><div><div></div><blockquote type="cite"><div><span style="background-color: rgba(255, 255, 255, 0);">b) if Onion addresses have 2+ forms, one like the current (<font><a href="http://www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion/" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">www.</a><a href="http://www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion/" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.</a><a href="http://www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion/" dir="ltr" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">onion</a></font>) and the other being apparently more human-usable because it contains a CRC, the one which allows access to websites will win.</span></div></blockquote><div><br></div><div>What if they both allow access to websites?</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>I had always thought that prop#279 addresses would be</div><div>translated into their canonical forms before the browser</div><div>acts on them. But the current proof-of-concept</div><div>implementation would include them in the Host header,</div><div>because the translation is done at the Tor layer</div><div>(not the browser layer).</div><div><br></div><div>This also makes a mess of security certificates.</div><div>(Or it means that both names would need to be in the certificate.)</div><div><br></div><div>And there's the issue of having two names for the same site.</div><div><br></div><blockquote type="cite"><div><span style="background-color: rgba(255, 255, 255, 0);">My expectation to date has been that the problem with "4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad" is that that there is no place for the eyeball to rest when typing it in; as such I've presumed that a canonical form, defined by Tor, would be something like:</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><a href="https://www/">https://www</a>.4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad.onion/</span></font></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> ...being N groups of M characters (where N and M can be argued, feel free...)</span></div></blockquote><div><br></div>That's not what's specified right now, and it not what will be</div><div>released in 0.3.2 in a few weeks.<br><div><br></div>But we could implement a grouping and checksum mechanism</div><div>like this using a prop#279 plugin, much like the bech transform.</div><div><br></div><div>Depending on where we do the name translation, this change</div><div>would cause the same Host header and certificate issues.</div><div><div><br></div><blockquote type="cite"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif">The advantage of a system like this is that it's not perfect, but a typo mostly has to happen twice and be quite fortunate to go undetected.</font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif">Of course it's not perfect, but nothing will be, and clever selection of checksum and encoding will result in something which is still DNS- and Browser-compliant.</font></span></div></div></div></blockquote><div><br></div><div>One other advantage: a DNS-format-compliant checksum like this could be trivially baked into an SSL certificate without requiring CA/Browser Forum to invent a wholly new kind of certificate just-for-Tor</div></div></blockquote><div><br></div><div>This is true. We should make any schemes DNS-compliant,</div><div>which is how the examples in prop#279 work.</div><br><blockquote type="cite"><div><div>This would result in Prop224 Onion Addresses which would not only be typo-resistant, but could also continue to be issued with EV certificates where site-attestation is beneficial.</div><div><br></div><div>Further: adding segment-checksum bits at the end would be (I think?) backwards compatible with existing Prop224 addresses.</div></div></blockquote><div><br></div>They would be compatible, as would most prop#279 addresses,</div><div>apart from the issues mentioned above.<br><br><div>Are you aware that there's already a checksum in v3 onion</div><div>service addresses?</div><div><br></div><div><pre style="padding: 0px; margin-top: 0px; margin-bottom: 0px;"><font face="UICTFontTextStyleTallBody"><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);">"The onion address of a hidden service includes its identity public key,</span></font></pre><pre style="padding: 0px; margin-top: 0px; margin-bottom: 0px;"><font face="UICTFontTextStyleTallBody"><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);">a
version field and a basic checksum."</span></font></pre></div><div><br></div><div><a href="https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n2012">https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n2012</a></div></div><div><br></div><div>T</div></body></html>