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