144 lines
12 KiB
Plaintext
144 lines
12 KiB
Plaintext
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.
|