[tor-dev] Error-Correcting Onions with Bech32

[teor]

Hi,

> b) if Onion addresses have 2+ forms, one like the current (www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion) and the other being apparently more human-usable because it contains a CRC, the one which allows access to websites will win.

What if they both allow access to websites?

I had always thought that prop#279 addresses would be
translated into their canonical forms before the browser
acts on them. But the current proof-of-concept
implementation would include them in the Host header,
because the translation is done at the Tor layer
(not the browser layer).

This also makes a mess of security certificates.
(Or it means that both names would need to be in the certificate.)

And there's the issue of having two names for the same site.

> 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:
> 
> https://www.4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad.onion/
> 
>  ...being N groups of M characters (where N and M can be argued, feel free...)

That's not what's specified right now, and it not what will be
released in 0.3.2 in a few weeks.

But we could implement a grouping and checksum mechanism
like this using a prop#279 plugin, much like the bech transform.

Depending on where we do the name translation, this change
would cause the same Host header and certificate issues.

>> 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.
>> 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.
> 
> 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

This is true. We should make any schemes DNS-compliant,
which is how the examples in prop#279 work.

> 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.
> 
> Further: adding segment-checksum bits at the end would be (I think?) backwards compatible with existing Prop224 addresses.

They would be compatible, as would most prop#279 addresses,
apart from the issues mentioned above.

Are you aware that there's already a checksum in v3 onion
service addresses?

"The onion address of a hidden service includes its identity public key,
a version field and a basic checksum."

https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n2012

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171231/6de963d0/attachment.html>