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
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
