On 01 Nov (14:28:03), teor wrote: > > > On 31 Oct 2017, at 06:57, David Goulet <dgoulet@xxxxxxxxx> wrote: > > > > * I believe now that we should seriously discuss the relevance of channels. > > Originally, the idea was good that is providing an abstraction layer for the > > relay to relay handshake and send/process cells related to the protocol. But, > > as of now, they are half doing it. > > > > There is an important cost in code and maintanance of something that is not > > properly implemented/finished (channel abstraction) and also something that > > is unused. An abstraction implemented only for one thing is not really useful > > except maybe to offer an example for others? But we aren't providing a good > > example right now imo... > > > > That being said, we can spend time fixing the channel subsystem, trying to > > turn it in a nicer interface, fixing all the issues I've described above (and > > I suspect there might be more) so the cell scheduler can play nicely with > > channels. Or, we could rip them off eliminating lots of code and reducing our > > technical debt. I would like us to think about what we want seriously because > > that channel subsystem is _complicated_ and very few of us fully understands > > it afaict. > > It depends what the goal of the channel layer is. > > Do we seriously think we will use another protocol in place of TLS? > > Even if we are serious about non-TLS connections, do we want to rip out > this code now, and write something better when we know what we > actually need? Right, that is basically a very good question to try to answer. I think it is totally conceivable to think about researchers willing to experiement there and go with a Tor without TLS. At that point, channel could be useful but in a state that actually is a proper abstraction (not the case right now). We would need work to make it happen. However, I do *NOT* see Tor moving away from TLS anytime soon. The network and clients out there are all using that, moving to something else would mean dual stack protocol, years of ramping up to network maturity (basically ntor vs tap is a good example I think). But at that point, we'll have to do massive amount of work in the channel/connection subsystem. All in all, my answer is that "No, we aren't serious about moving away from TLS but always possible". Thus, in the end, this channel subsystem is really about letting researchers play with it and not helping us developers do our job. There could be a gain there of fixing it but would be one sided for now imo. > > Is the channel layer the right place to hide the differences between > TLS-over-IPv4 and TLS-over-IPv6? That would be the connection layer, handling 1 to 1 socket connection and talking to the kernel. SCTP-Tor for instance, would also be at the connection layer. That subsystem in my opinion would benefit *greatly* for a nice interface but that is huge amount of work. Thus, I want to re-iterate that if we care about providing a nice abstraction for researchers to do a better job, we have a broken one at the channel layer and none at the connection layer which is actually the one that would be most useful (QUIC, SCTP, UDP, ...). So even today we do *not* offer anything useful to researchers imo. Cheers! David > (I don't think it is, but it's worth thinking about how much work it > was to add IPv6 support, and using that as a guide for how much work > it would be to add address/port/keys/etc. for another protocol.) > > T > > -- > Tim / teor > > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > ------------------------------------------------------------------------ > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- sGwH3ikKXaZjLVTHXKbL8U8r+dQrx5mLsny/C4ZarV4=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev