@eyedeekay
+R4SAS
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest24901
Irc2PGuest84457
Irc2PGuest93562
Nausicaa
Onn4l7h
Onn4|7h
T3s|4_
aargh
anon3
cancername
eyedeekay_bnc
l337s
not_bob_afk
profetikla
qend-irc2p
u5657
x74a6
orignal
hi
eyedeekay
Hi orignal
eyedeekay
Hi everyone welcome to the meeting for the 21st, sorry I was a little late
eyedeekay
Who all is here?
orignal
seems nobody
eyedeekay
What's on the agenda? I have 1) release and 2) SSU2 RI in SessionRequest
orignal
please give voice to xeiaso
orignal
nice
xeiaso
hi
orignal
let's talk about release
orignal
eveything works good from my side
eyedeekay
Same here, we've had lots of time to test our changes, looks good, I'll be ramping up for us to release on the 26th
xeiaso
good to see its on schedule
orignal
so tomorrow
eyedeekay
No 1 week from today, it's the 19th
orignal
so postponed for 1 more week?
eyedeekay
Yeah, I had to push it back a week because my laptop died, had to find a replacement and get my work environment set back up
eyedeekay
Anyhow, we're on track for that date.
orignal
wut? your lattop died?
orignal
and you don't have any other computerss?
eyedeekay
I don't have any other ones with all my keys on them except for a backup locked in my office
eyedeekay
Got locked out of everything without the keys. I can work fine on another computer, but can't check anything in from them
orignal
and you don't have local storage I guess
orignal
you shoould organize your work envirnment first
orignal
to make sure that death of your laptop or PC doesn't postpone release
eyedeekay
I didn't have a backup of my keys on my person at the time the laptop died no. Actually I thought I had, but what I actually had was a portable hard drive that made a strange grinding sound
susdo
oof gotta backup my keys
eyedeekay
At any rate, the delay for me between broken-laptop-to-recovered-environment should be down to around 48 hours in the worst case scenario now, if nothing I'm carrying works I can still get it from the backup in my office
orignal
setup local NAS
orignal
with RAID1 in it
orignal
I thought it was obvious
eyedeekay
Sure if I'm stationary, if I'm travelling then that does me little good
orignal
are you travelling now?
eyedeekay
Not anymore as of last week
eyedeekay
I'll get around to setting up a NAS soon
eyedeekay
When do you want to do the next release after this one?
eyedeekay
September?
orignal
so what's included to the next release?
orignal
whenever you are ready
xeiaso
wouldn't meeting point 2) be included in the next release?
orignal
if we agree what we do
eyedeekay
For Java I2P?
eyedeekay
We have an option to set an expiration time for blocklist entries, we've got fixes for the messageID replay leak, and we've changed how we validate inbound messages
eyedeekay
Yes, I thought we were still talking about 2.3.0
eyedeekay
I would like to target SSU2 changes to 2.4.0, I'm on board with the routerIdent-in-SessionRequest thing per one or two pending questions
eyedeekay
Figure we can get to them in 2)
orignal
so, what's you opinion?
eyedeekay
On SSU2? I like early validation and early dropping, it means less overhead and earlier effectiveness. routerIdent-in-SessionRequest gets us that
eyedeekay
And it makes the clone attack ineffective AFAICT
orignal
do you have an offical proposal?
eyedeekay
No, I do not. What I need is for us to fit it into the official specification. I would like it very much if you wrote the proposal, since it is your idea and you probably understand it best. Doesn't need to be long
orignal
will try
eyedeekay
Thanks
eyedeekay
For folks keeping score at home we've moved on to discussing 2)
eyedeekay
I do have one kind of concern about this idea, though, which regards obfuscation
orignal
obsfuscation?
orignal
where?
eyedeekay
Where is part of my question: does does including the routerIdent in the SessionRequest make it easier for an attacker to say "this is definitely SSU2," or alternately, "this is definitely an I2P session?"
orignal
no, it's just one more block
orignal
it goes as chacha20 encrypted payload
eyedeekay
OK
orignal
we have 4 block already if I remeber
eyedeekay
Yeah
eyedeekay
OK I'm still going to squint at it but if you can do a proposal for it we can work on it for 2.4.0, tenatively mid-September
eyedeekay
Anything else for 2)?
orignal
no
orignal
ofc I don't know my plans for september yet
eyedeekay
OK. Lots of time to coordinate in between now and then, just ping me if you need to let me know of your plans
eyedeekay
OK any other topics for the meeting?
xeiaso
what about 3) netDB modularization? I noticed i2pd seems to do this
eyedeekay
Yes they do, something orignal's been suggesting we try for a long time IIRC
orignal
xeiaso you mean netdb per desatination?
xeiaso
yes
orignal
ofc it should be done
orignal
because that attacks still possible
eyedeekay
We're considering the idea of making it so that it is possible to use different netDbs based on where a message came in, i.e. per-destination
orignal
if you run your destination on a floodfill
eyedeekay
It's a lot of work for us to do this and our extant defenses make the job a little complex and unclear, there are literally hundreds of places where the netDb is accessed in Java I2P, at least 280 that I've got to review so far for this process
xeiaso
oh?
xeiaso
orignal: why is it floodfill specific?
eyedeekay
But branch on git.idk.i2p/idk/i2p.i2p i2p.i2p.2.2.1-nested-netdb contains a prototype
eyedeekay
orignal IIRC you have a blog post somewhere about this, do you remember where it is?
orignal
because you can submit LeaseSet to floodfill directly
orignal
unlike regural router
orignal
no I even didn't know you had a blog ))
xeiaso
Java I2P allows direct submission to regular routers
eyedeekay
Not my blog, your blog
eyedeekay
Or maybe acetone's?
orignal
my blog? I never wrote blog
orignal
yes, acetone
eyedeekay
Hm. Must be misremembering
orignal
probably on habr
orignal
xeiaso Java I2P has shared netdb between router and destinations
eyedeekay
OK. I'll look for it later then, want to review it for researching our implementation
orignal
if you submit a LeaseSet to a floodfill
orignal
one of destinations might see it
orignal
and it can lead to deanon
eyedeekay
Anyway, this is something we're looking at, which we're trying to figure out the right way to do it
eyedeekay
Knowing more about the scenarios where an attack might be possible, so we can evaluate if it's real, and where and how to handle it, is part of what needs to happen to do that
eyedeekay
That's all I have to add for 3)
orignal
there are at least 3 working scenario
orignal
I descibed all of them and sent to gradpa long time ago
eyedeekay
Can you PM them to me, or send them in an email?
orignal
it was few years ago
orignal
need soem time to remember
eyedeekay
I don't have access to grandpa's email so anything you recall would be appreciated
orignal
and grandpa agreed that such problem existed
orignal
no it was in IRC
eyedeekay
Oh, bummer
eyedeekay
Well I have even less access to that
xeiaso
what is old is new
orignal
but the basic idea that router's LeaseSets and destination's LeaseSets can overlap
orignal
e.g. destination might use LeaseSet submitted to router directly
orignal
and vice-versa
eyedeekay
Yeah, and if you can get one you sent to one from the other, then you can determine that they're both sharing a netDB and on the same router
xeiaso
or a LeaseSet submitted to a router might already be a destination on that router
orignal
it migth be special LeaseSet prepared for deanon
eyedeekay
Pretty straightforward in principle, in practice we've got calls to get the context-wide netDB all over the place
eyedeekay
So tracing them all is the biggest part of the work now
eyedeekay
Something like 300 or so calls
eyedeekay
I'm still identifying more, that's why it will help to know where the existing issues may be
eyedeekay
Anything else on 3?
orignal
no
eyedeekay
Anything else for the meeting?
xeiaso
no
eyedeekay
OK thanks everybody for coming, see you around IRC, if you're interested in the segmentation approach see that branch I posted above
eyedeekay
See you next time on the 7th
eyedeekay
Oops, make that the 3rd