I2P dev meeting, April 22, 2014 @ 20:30 UTC
hottuna, nombre_, psi, str4d, zzz2
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", -- firstname.lastname@example.org 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 [email@example.com] 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 [firstname.lastname@example.org] 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.