[tor-dev] "old style" hidden services after Prop224

[Ivan Markin]

Hi Razvan,

Razvan Dragomirescu:
> I've developed against the current hidden service infrastructure and it
> appears to work like a charm, but I'm a bit worried about Prop224. That
> will break both the OnionBalance-like service re-registration that I'm
> using _and_ the OnionCat HS to IP6 mapping. I know that efforts are in
> place to upgrade the two in view of Prop224 but I'm wondering if there's
> any good reason to drop support for "old style" hidden services once
> Prop224 is fully deployed.

No worries, prop224 is not going to break OnionBalance-like
re-registration - it's just going to make it more complicated. One will
have to perform cross-certification trickery in order to reassemble
intropoints of another onion service. We want to avoid this plain
"re-registration" since anyone can do it (for details see #15951 [1]).
The way out is to add a feature into little-t-tor and to rewrite tools
like OnionBalance, avant, etc to fetch intropoint list from backend
services directly (via ControlPort or special onion address) thus going
without posting useless descriptors to HSDirs and fetch them from HSDirs
again.

Yes, in case of OnionCat onion<->IPv6 mapping we got a problem. It's
just because address length is 80bit for legacy, 256bit for prop224 and
<128bit for IPv6. And one have to use something additional (like DHT for
cjdns) to "resolve" short IPv6 into larger Ed25519. Apparently IPv6 is
good but not enough to be used as public keys. IMO we need something
better* for this.

Also you'll likely have issues with migration from RSA1024 to Ed25519 on
your smartcards. Most (Java) cards I know have built-in RSA engine and
any additional crypto may not fit in or be slow.

So my two cents is to migrate to prop224 as soon as possible and make
everyone secure (RSA1024 and SHA1 are baaaad).

* Maybe just hostnames with variable length?
[1] https://trac.torproject.org/projects/tor/ticket/15951
--
Ivan Markin