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

[Razvan Dragomirescu]

Thank you Ivan! I still dont see a very good reason to _replace_ the
current HS system with the one in Prop224 and not run the two in parallel.
Why not let the client decide what format and security features it wants
for its services?

Razvan

On 13 Sep 2016 00:37, "Ivan Markin" <twim at riseup.net> wrote:

> 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
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160913/7b79c8ec/attachment.html>