I2P dev meeting, April 22, 2014 @ 20:30 UTC

Quick recap

  • Present:

    hottuna, nombre_, psi, str4d, zzz2

Pełny protokół IRC

20:32:31  <str4d> Hi all
20:34:53  <str4d> 0) Hi
20:34:53  <str4d> 1) TODO 0.9.13-0.9.16 http://zzz.i2p/topics/1600
20:34:53  <str4d> 2) New transport for Tor PTs http://zzz.i2p/topics/1551
20:34:53  <str4d> 3) Any items that emerge from 1)
20:34:53  <str4d> Post-meeting activity: Stress-testing Mumble (voice chat over I2P)
20:35:07  <iRelay> Title: zzz.i2p: TODO 0.9.13 - 0.9.16 (at zzz.i2p)
20:35:10  <iRelay> Title: zzz.i2p: Supporting Tor Pluggable Transports (at zzz.i2p)
20:35:29  <str4d> 0) Hi
20:35:57  <hottuna> Hello
20:37:37  <str4d> Anyone else?
20:38:01  <str4d> zzz2 orion psi kytv meeh_
20:41:17  <str4d> Hopefully some of them will turn up.
20:41:17  <str4d> 1) TODO 0.9.13-0.9.16 http://zzz.i2p/topics/1600
20:41:22  <iRelay> Title: zzz.i2p: TODO 0.9.13 - 0.9.16 (at zzz.i2p)
20:41:26  <zzz2> here
20:41:58  <str4d> At zzz's request we started a discussion thread to propose ideas for the I2P roadmap moving forward.
20:42:27  <str4d> There was a lot of chatter, but no actual consensus was reached.
20:43:14  <str4d> I summarized some of the initial suggestions on the roadmap page http://trac.i2p2.i2p/wiki/Roadmaps/1.0
20:43:17  <iRelay> Title: Roadmaps/1.0 – I2P Bugtracker (at trac.i2p2.i2p)
20:45:01  <str4d> zzz2: I see you have been getting stuck into susimail (yay)
20:46:19  <zzz2> yeah, fell down that rathole while we try to decide what's really important
20:52:07  <str4d> I think that it was useful work, if only because there is a long-standing bug about login problems, and susimail is one of the first apps that users are going to try
20:52:08  <str4d> http://trac.i2p2.i2p/ticket/747
20:52:12  <iRelay> Title: #747 (Login problems with Susimail) – I2P Bugtracker (at trac.i2p2.i2p)
20:54:45  <psi> str4d: ohai
20:54:47  * psi is late?
20:55:19  <str4d> yes psi is
20:55:25  <str4d> Nothing much has happened yet :/
20:55:58  * psi scrolls up
20:56:07  <str4d> To summarize what has been going on since the RFC was put out:
20:56:18  <str4d> - zzz has worked on susimail
20:56:59  <str4d> - psi has been getting his head around PTs, new DH and JNI
20:57:23  <str4d> - I have been working on I2P-Bote Android, and now Java EdDSA
20:57:39  * psi has been spending the entire day fleshing out the structure of PT for i2p
20:58:59  <zzz2> if str4d and psi are making progress on EdDSA, 25519, and PTs, then I think the best use of my time is moving forward on new sig algo migration, e.g. multiple dests down a tunnel, and some sort of addressbook support
21:00:27  <jenkins@kyirc> Starting build #581 for job I2P
21:01:01  <zzz2> whats the status of psi mtn keys and dev agreement? I've gotten nothing in the mail.
21:01:23  <str4d> psi signed the dev agreement, I pushed it to the website
21:01:36  <str4d> (so his pub keys are on record)
21:02:10  <zzz2> his key fingerprint is on there too?
21:02:32  <zzz2> if so I'll add him and announce it
21:03:02  <psi> my gpg fp is on my twitter
21:03:05  <str4d> not the fingerprint, but the key itself is
21:03:47  <zzz2> it needs to be in that sample monotonerc template file. psi maybe you can do that as your first test of mtn skills?
21:04:23  <jenkins@kyirc> Yippee, build fixed!
21:04:24  <jenkins@kyirc> Project I2P build #581: FIXED in 3 min 55 sec: http://jenkins.killyourtv.i2p/job/I2P/581/
21:04:36  <psi> i can get that
21:04:40  <psi> i already did that locally
21:04:53  <str4d> zzz2, psi, I have updated the roadmap Gantt - http://trac.i2p2.i2p/wiki/Roadmaps/1.0
21:04:56  <iRelay> Title: Roadmaps/1.0 – I2P Bugtracker (at trac.i2p2.i2p)
21:05:21  <psi> the monotone key fp for my NOT transport key is "1ceb85b992114bae1bcb156ef238f8f3044a6bfe",     --  ampernand@gmail.com
21:06:04  <psi> i can get my transport key fp as well
21:06:29  <zzz2> ok great, welcome to the team! As I tell everybody, please be careful, practice on www first
21:06:30  <str4d> psi: you need to send that to eche, kytv and welt
21:06:43  <str4d> +1
21:06:56  * kytv got it and is adding it to his server
21:07:08  <zzz2> psi, we have very precise instructions on how to do all this on the web page... :)
21:07:27  <psi> i will review that
21:07:38  <zzz2> e.g., send me mail (but no longer needed for you)
21:08:15  <str4d> How does the Gantt roadmap look to everyone now? Are there any items that seem unrealistic, or any that are missing
21:08:16  <str4d> ?
21:09:37  * psi reviews roadmap
21:09:43  <jenkins@kyirc> Project I2P UnitTests build #528: SUCCESS in 5 min 6 sec: http://jenkins.killyourtv.i2p/job/UnitTests/528/
21:09:57  <jenkins@kyirc> Starting build #82 for job I2P-Android
21:09:59  <str4d> zzz2: I suggest that you get the new GPG keys item out of the way sooner rather than later ;)
21:10:19  <zzz2> str4d, please tell us what it's telling you about what's important
21:10:33  <str4d> psi: are you finding much overlap between your PTs work and NTCP2?
21:10:34  <zzz2> yes I'll do it before the next release, I promise
21:11:24  <str4d> IMHO there are three things that are important:
21:11:32  <jenkins@kyirc> Project I2P-Android build #82: SUCCESS in 1 min 34 sec: http://jenkins.killyourtv.i2p/job/I2P-Android/82/
21:11:40  <str4d> 1) progress on the crypto upgrade - now finally getting underway
21:12:01  <psi> str4d: at the moment, i have yet to look at ntcp2
21:12:13  <str4d> (continuing on from the prep work)
21:13:28  <zzz2> 1) "now getting underway" ?  I've been busting ass on it for 6 months
21:13:32  <str4d> 2) Audit prep - IMHO we need to get on top of our threat model etc. ASAP
21:15:33  * psi afks for 30 minutes
21:15:33  <psi> unexpected event bbl
21:15:33  <psi> i will look at scrollback later
21:16:21  <zzz2> There seems to be some confusion out there about "new signing crypto".  It's done, it's out there in 0.9.12, it works. For destinations.
21:17:06  <zzz2> The "only" thing not done is migrating existing published destinations to a new one.
21:21:13  <str4d> yes, which first relies on choosing a new one, which IMHO should be Ed25519, which relies on getting a fast impl.
21:21:15  <str4d> And at the same time, I agree that the remaining required migration infrastructure should be implemented.
21:21:16  <str4d> <str4d> For years we have left it to the side and worked on what we think is beneficial to users, but IMHO if we want to start getting more research interest, and utilize it effectively, we need to be more conscious of what I2P can and cannot achieve.
21:21:17  <str4d> <str4d> I know you have zzz ;P
21:21:18  <str4d> <str4d> (I was specifically referring to the part of it involving the actual new crypto)
21:21:19  <str4d> <str4d> thank you for the effort you have put into getting it this far :)
21:21:20  <str4d> <str4d> 3) Usability, UX - this is a third important point that is not on the Roadmap chart
21:21:22  <str4d> <str4d> Well - zzz's susimail work falls into that category, as does streaming improvements
21:21:41  <str4d> <str4d> But also important is reviewing our error and help pages, and how we aid the user in getting their jobs done.
21:21:41  <str4d> (after my "2) Audit prep" line)
21:22:00  <str4d> I need to go AFK in 10-15 mins
21:22:50  <str4d> And since psi is AFK, I'm dropping "2) New transport for Tor PTs" from this meeting
21:23:55  <str4d> zzz2: in your opinion, what do we need to do before organizing a meeting with Lance re: threat model?
21:24:59  * str4d would like to try for a meeting with Lance in May
21:26:04  <str4d> so we need to work out what we need to do before then, so we can organize the meeting with enough time to finish that first.
21:29:27  <zzz2> I disagree that we first have to choose.
21:29:59  <zzz2> Or, that we can choose now (P256) and choose again later when more options are available.
21:30:02  <MTN@kyirc> [ I2P ] compile fix [zzz@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/12396c3ee88d1194482fc2cc3751db1169cc52e3
21:30:34  <zzz2> We could switch the default for new dests to P256 in 0.9.13 if we want.
21:30:35  <str4d> zzz2: if we get to the stage where the naming system can cope with dynamic enc choices, then I agree
21:31:05  <zzz2> P256 is clearly better than DSA
21:31:34  <str4d> I also agree there.
21:31:43  <zzz2> I think the P256 haters better take a step back and think about how bad DSA 1024 is.
21:32:03  <MTN@kyirc> [ WWW ] adding psi's transport key [kytv@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/029163d2d446f10ab1a129b559802fabac2ef8b7
21:32:52  <str4d> zzz2: I understand your point.
21:33:39  <zzz2> re: audit and Lance, it's always a good time. you have an audit process update for us from the mailing list?
21:33:40  <str4d> Part of my reason for wanting to get EdDSA working before the switch is that based on what you have said in threads before, I wouldn't look forward to switching Dest signing algo twice.
21:34:14  <str4d> yes, the second time would be a bit easier because multi dest support etc. would be there, but the naming side is still the weakness.
21:34:48  <zzz2> for servers you don't want to switch twice, but for clients it doesnt matter
21:35:04  <str4d> good point.
21:35:23  <str4d> Is there anything that would prevent new Dests talking with old ones?
21:35:31  <nombre_> so i gather you guys are doing crypto upgrades? is there perhaps a page that goes into detail on what all you're planning? and on a 25519 implementation, you could just use nacl via jni, or kalium, tho that might be somewhat limiting
21:35:34  <zzz2> and even for servers,  if you switch to P256 it hardly seems worth it to switch again, unless some really bad news comes out about P256
21:35:54  <str4d> If not, it could be a good idea to get clients onto P256 sooner
21:36:08  <zzz2> new dests can talk to old and vice versa, as long as both are on 0.9.12 or later
21:36:39  <str4d> zzz2: http://blog.cr.yp.to/20140323-ecdsa.html is reason enough for me to not want to stay on ECDSA
21:36:43  <iRelay> Title: cr.yp.to: 2014.03.23: How to design an elliptic-curve signature system (at blog.cr.yp.to)
21:37:56  <str4d> not for any one single point (yet), but if we can get an effective, *correct* implementation of EdDSA, I think it would be very beneficial to switch
21:38:27  <str4d> nombre_: http://trac.i2p2.i2p/ticket/856
21:38:30  <iRelay> Title: #856 (Crypto review/migration) – I2P Bugtracker (at trac.i2p2.i2p)
21:38:30  <str4d> (and links therein)
21:38:40  <nombre_> thx str4d
21:38:53  <zzz2> nothing there tells me to delay getting rid of DSA though. There's nothing in there that makes me panic about P256 either. Is there anything better than P256? sure.
21:39:15  <str4d> zzz2: no real updates as such from the OpenITP mailing list, there hasn't been much real activity lately.
21:40:38  <zzz2> I allowed for 65536 signing algos and I implemented 7. 65529 to go, we can add a few every release if we like.
21:43:27  <str4d> zzz, I would support moving clients to p256 in 0.9.13
21:44:47  <str4d> but if the server transition is still not going to be smooth, I'd rayher hold off a bit and see how EdDSA work goes.
21:45:49  <nombre_> as would i (not that my opinion counts for anything), nist ecdsa is better than dsa, even if some of us tinfoilers won't feel secure until its 25519
21:46:48  <nombre_> dest/b32 breaking is sorta a given tho yes?
21:47:13  <str4d> it's taken a long time and a lot of work to get to this point, no sense rushing at the last minute
21:49:48  * RN pokes head in and looks around
21:54:36  <zzz2> there's 1) clients 2) new servers and 3) existing server migration.
21:54:43  <zzz2> 1 and 2 we can do now, 3) takes a lot more work.
21:54:59  <zzz2>  1 and 2 breaks compatibility with old routers, i2pcpp, and i2pd though, until they catch up
21:55:16  <nombre_> so is there someone working on finding/creating a java implementation of 25519? and whats the estimated timeframe on when it would be usable?
21:55:28  <nombre_> i assume with p256, its already doable because thats included in bouncy castle?
21:55:52  <zzz2> p256 is in the jvm
21:56:06  <nombre_> ah even better
21:56:17  <zzz2> we have 25519 java now but it's far too slow to be usable. str4d and psi are trying to speed it up
21:57:39  <nombre_> hmm well not knowing anything about crypto, i would think using jni would be the simplest way to speed it up. perhaps i should look into 25519 more to understand what parts of it are the bottlenecks
23:02:36  <str4d> No one actually ended it when I went afk, so:
23:02:53  * str4d *baf*s the meeting closed.