Establish definitive Kovri design and use-case.

[anonimal]

Tl;dr: "eliminate sam/bob/http router console/and more in order to become a easily maintainable, more-likely-to-be-easily-reviewed smaller router that is geared toward a hosting a single i2cp server (API accessible)".

This will provide a greater likelihood of maintaining a very secured router; far greater than what i2pd can currently offer. Also, think 'OpenBSD-rigorousness' in terms of design and decision.

2015-12-02  zzz [14:53:35] anonimal, only guessing, but TLS is probably only used for reseed now
2015-12-02  zzz [14:53:57] near future: use it for i2pcontrol (orignal has recently done this in his branch)
2015-12-02  zzz [14:54:30] longer term: optional for i2ptunnel clients and servers, SAM, BOB, ...
2015-12-02  +psi [14:59:43] and i2cp
2015-12-02  zzz [15:15:33] yup
2015-12-02  zzz [15:16:26] on the java side, it isn't always pretty, and it's taken several years, but we finally have utility classes to easily use SSL/TLS securely, and create/manage keys, certs, and passwords for server and client side
2015-12-02  zzz [15:21:22] stuff like disabling the old protocols and ciphers, and doing hostname verification, isn't at all easy or obvious in Java, but it's important. Only got all that right in the last year or so.
2015-12-02  zzz [15:22:27] and bad CAs like eDellRoot... just did that the other day. It never stops.
2015-12-02  +psi [15:23:46] tls and the CAs suck, it's the real house of cards
2015-12-02  zzz [15:25:41] one thing we don't do yet that you might consider is cert pinning for the reseeds
2015-12-02  zzz [15:27:40] but that makes management harder due to renewals and the chance of 'pinning suicide'
2015-12-02  anonimal Yes, only used for reseed.
2015-12-02  anonimal And when I said in the ticket "after that, any use of TLS would be an added bonus and not critical nor a core function of I2P", I included SSL for i2pc*, sam/bob
2015-12-02  anonimal Because frankly, I don't see a need for that.
2015-12-02  anonimal Even though it is implemented elsewhere.
2015-12-02  anonimal Why ssl when an ssh tunnel would suffice
2015-12-02  anonimal And how many app developers really use ssl over those protocols?
2015-12-02  anonimal I can think of setups where it would be useful, but don't forget http://www.danielsen.com/jokes/objecttoaster.txt
2015-12-02  anonimal I need more information though instead of a "just do it". If anyone could help with some perspective, that would be great.
2015-12-02  anonimal What I will do since psi appears to not want to respond to #3 is make a move with openssl and just get this reseed business finished.
2015-12-02  +psi huh?
2015-12-02  * psi reads
2015-12-02  +psi re: reseed str4d suggested that reseed could be done via tor's PT
2015-12-02  str4d anonimal, ssh is only "easy" for more technically-minded people
2015-12-02  str4d whereas ssl is just a checkbox
2015-12-02  anonimal zzz: I forgot to ping you re: perspective
2015-12-03  str4d (although its UX is also not simple right now, but it is much easier to make it so)
2015-12-03  anonimal But can someone give me an example of an app that actually uses ssl?
2015-12-03  anonimal Story of my life http://www.danielsen.com/jokes/objecttoaster.txt
2015-12-03  str4d anonimal_, there's no "app" that uses SSL, because it's not a feature of an app. It's a feature of the library and/or API
2015-12-03  str4d As currently set up, it's up to the user to choose to enable it, because SSL is enabled without changing the port, ie. either all clients use it or none, not both
2015-12-03  &anonimal Yes, SSL incumbent upon the API, but what I'm asking is when is it actually needed outside of reseed.
2015-12-03  &anonimal And the only answers I'm seeing are "user optional".
2015-12-03  &anonimal Its safer to keep everything loopback but yes, at a flexibility cost.
2015-12-03  &anonimal But I'm questioning the tradeoff, and that's why I'd like to see more use cases.
2015-12-03  &anonimal My point: if one is technically minded enough to need to SSL for non-reseed, then they are a stones-throw away from other safer methods.
2015-12-03  &anonimal But if this feature is in huge demand, then I'll proceed in that direction.
2015-12-03  &anonimal (ssl for all)
2015-12-03  zzz anonimal, what str4d said, and also it's not used that often, but perhaps the most likely would be an HTTPS router console, and i2ptunnel server forwarding to a remote web server over SSL
2015-12-03  str4d anonimal, my point is that yes it may be optional, but cutting it out because "you can do ssh" is not IMHO a good answer.
2015-12-03  str4d I don't think SSL for non-reseed mandates being technically minded. It could easily be "The guide I was following recommended it", or just "SSL is enabled by default" in future perhaps
2015-12-03  &anonimal I'm sold on i2ptunnel server forwarding. Everything else had a good point but that was the straw that broke the camel's back.
2015-12-03  &anonimal More importantly, this brings up core kovri questions like: what is kovri's intent and do all of the aforementioned APIs and complexies fit into this router's role?
2015-12-03  &anonimal i2pd is obviously an attempt to clone java i2p, but how is kovri evolving?
2015-12-03  * anonimal open-ended questions
2015-12-03  &anonimal Will kovri eliminate sam/bob/http router console/and more in order to become a easily maintainable, more-likely-to-be-easily-reviewed smaller router that is geared toward a hosting a single i2cp server?
2015-12-03  &anonimal The more I live with this code, the more I realize that most of these kinds of questions were never asked in the first place.
2015-12-03  &anonimal And I don't even think that Linus Torvalds would have been foolish enough to think that a single person could adequately cover so many bases in the earliest version of linux.
2015-12-03  &anonimal And he's linus.
2015-12-03  &anonimal fluffypon: ^
2015-12-03  str4d Thing to remember: SAM and BOB are on the client side of I2CP
2015-12-03  str4d ie the libi2p / libkovri side
2015-12-03  str4d So the kovri router itself could easily just be a small router hosting an I2CP server
2015-12-03  str4d In Java I2P'
2015-12-03  str4d s case, the routerconsole does get access to the router side via RouterContext, but everything else could in theory be run separately
2015-12-03  str4d and the idea of I2PControl is to provide some (if not all) of the functionality that the routerconsole currently gets via RouterContext, so it *could* be implemented separately
2015-12-03  str4d anonimal, this partly falls into the code reorganization stuff
2015-12-03  &anonimal Thanks str4d for the affirmation. I'll need more time to think, but I like this direction.
2015-12-03  str4d It's the reason I2CP was put into the Java router - to create a definite separation of concerns
2015-12-03  str4d And you get the benefit of being able to immediately use any Java I2P app with kovri. Even non-Java apps could be used by running a standalone Java SAM API connecting to the kovri router via I2CP.
2015-12-03  &anonimal Oh, good point, lol. My mistake ;)
2015-12-03  &anonimal Wow, great points to re: apps.
2015-12-03  &anonimal s/to/too/

Note: we would replace router console with an ncurses UI (as proposed pre-Kovri) similar to Tor's arm. Something that can interpret the TMI of our current logger into user-friendly reading.

Related to #5, #6, #9, #12, #33, #34.

[anonimal]

Blessings were given in today's meeting (#47) to proceed as proposed though I will hold off on a UI because of #53.

[anonimal]

I feel that this was resolved with 698641b. If we need to improve our definitions, we should open a new ticket.