@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest89954
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon2
cancername
eyedeekay_bnc
hk
not_bob_afk
profetikla
shiver_
u5657
x74a6
zzz
java.lang.IllegalArgumentException: TODO
orignal
was able to decrypt SessionCreated
orignal
AEAD failed
orignal
but it's about lenght of payload
orignal
decrypted SessionCreated
orignal
4 blocks
orignal
and one unknown block of type 17
zzz
for next time
orignal
so is it right block?
zzz
that's what the spec says, but we can talk about it. I put it in there because it's easy and there's plenty of room
zzz
but it could also go in the first ack I guess. Or with termination. or both.
orignal
so I'm done with SessionCreated
orignal
will implement SessionConfirmed probably today
zzz
fantastic
orignal
Noise works fine so far
zzz
0) Hi
zzz
hi
orignal
hi
eyedeekay
hi
zlatinb
hi
zzz
what's on the agenda for today?
orignal
SSU2 as usual
zzz
ok SSU2 is 1); what else?
zzz
eyedeekay, will you have a wikipedia update for us today?
eyedeekay
Nothing from me this week, just catching up to code, no substantial progress on the wikipedia thing yet, we haven't been able to determine if it's the classifier thing yet
zzz
ok, thanks
zzz
1) SSU2
zzz
orignal, I assume most of your status is above ^^^, anything else?
orignal
yes,
orignal
I would to discuss unpublished addresses
orignal
because I see some hole
orignal
SessionConfirmed and then data
orignal
very close to it
zzz
yeah, you're moving quickly
zzz
ok then. my status:
orignal
yesplease
zzz
I've been starting to code Peer Test and fix up the docs on peer test. slow going, all untested, will be a while
zzz
low priority
zzz
re: tokens, I looked at the QUIC docs
orignal
yes
orignal
good question
zzz
they bind only to IP. We want to bind to IP/port, which should be fine, because outbound port is fixed also
zzz
so I'm going to redo my caches to use IP/port for both outbound and inbound
orignal
and we might run multiple routers on the same IP
zzz
right
orignal
so, by endpoint only
zzz
correct
orignal
then I'm ready to request tokens first
zzz
I'm also researching using an "opaque token" which is a siphash of ip/port/timestamp or something
orignal
because tokens are not implemented yet on my side
zzz
so I don't have to remember what tokens I give out
zzz
but I don't know how to do that and still prevent token reuse
zzz
just an implementation idea, for now
orignal
how can it be reasued
orignal
other side shoudl verify it
zzz
tokens are opaque to the other side
orignal
ofc it must include endpoins of both sides
zzz
other side doesn't know what it "means"
zzz
so it could be, for example, siphash(ip, port, current hour)
zzz
but then you can't prevent it from being used again
orignal
I know what you mean
zlatinb
in Limewire we encrypted tokens with symmetric cypher with key known locally
zlatinb
then when receiving a token back we just decrypted and checked if valid
zzz
yeah, siphash is just a faster version of that zlatinb
zzz
the trick is to somehow remember it was used so somebody doesn't try to use it again
zzz
for further research, fyi only
zzz
next status item for me:
zzz
my outbound connections exploded today, because my IPv6 became firewalled, and that made my RI too big with introducers
zzz
even gzipped it was over 1400 bytes
zzz
and so didn't fit in the session confirmed
zzz
and splitting the RI across two messages is not quite specified and unimplemented
zzz
it's a mess
zzz
so one idea I had last week was making the padding in the router identity more compressible. not a general solutionm but might help long term
orignal
so what are we going to do?
orignal
I have better idea
zzz
well, what the spec says, if the RI is fragmented, don't accept any I2NP messages until you get the rest of the RI
zzz
it's just a state machine problem
orignal
replace 256+128 to 32+32
orignal
and without cert
zzz
that's my idea I discussed with zlatinb here a few days ago
orignal
use some "short" version
zzz
it's not really 32 + 32, it's 32 + (10x repeating pattern) + 32
zzz
so it gzips nicely
zzz
the "real" ident is still 391 bytes; but it gzips down to about 100
orignal
yes it makes sense
zzz
but even then, the full RI could still be bigger than the MTU
orignal
but it means you want compressed RI block
orignal
remeber it's uncomressed in NTCP2
zzz
we do have a compressed RI block now... it's in the SSU2 spec... I saw this problem coming months ago...
orignal
how about NTC2?
zzz
even with compression, I still went over 1500 this morning
zzz
no, not in NTCP2
orignal
good
zzz
I added an extra flag byte to SSU2 RI block
zzz
for 1) fragment and 2) gzip
zzz
something like that, don't remember exactly
zzz
SSU 1 specified router identity fragments, which was dumb, because router identity was only 387 bytes back then
zzz
but now we have full router info in session confirmed.
orignal
yes
zzz
so, another open issue. I need to go back and read what I wrote in the spec
orignal
we didn't send RI in sessionconfirmed
zzz
and look at the code to see how hard it would be to fragment
orignal
and we should now to verify s
zzz
right, SSU 1 only had router indentity, not full router info
zzz
so if you don't have full router info in session confirmed, you can't verify that s matches
orignal
basically you can
zzz
I don't want to specify something that's ugly to implement, so I want to think about it more
orignal
you can send identity + s + signature
zzz
kinda like SSU 1 again
orignal
I would prefer full RI
zzz
agreed
zzz
lets put it on the list for next week
zzz
and I think that's the end of my status
orignal
yes
zzz
anything else on 1) ?
orignal
no
zzz
anything else for the meeting?
orignal
not from my side
zzz
one more thing from me...
orignal
yes?
zzz
I've been thinking about doing a 4-6 part tweet about SSU2
zzz
saying it's one of the most secure and blocking-resistant protocols ever designed
orignal
4-6?
zzz
but maybe that's going too far
orignal
I would say it
orignal
it's just better than SSU
zzz
basic theme: SSU1 has been around for 17 years, almost never been blocked that we know of
orignal
because solves many problem
zzz
but we can do better. much better.
orignal
yes
eyedeekay
Might get us a free audit if you overstate it
zzz
taking the best of noise, wireguard, QUICK, 25519, blah blah blah
orignal
but I'm not sure if it would be better than NTCP2
zzz
ha
orignal
NTCP2 is too good now
zzz
my theory is that UDP is more censorship-resistant
zzz
because great firewalls can't deal with it very well
orignal
oh just remebered something
zzz
look at tor still getting blocked by everybody
orignal
what do you think about mtu of 64K?
zzz
for ygg?
orignal
yes
orignal
SSU2 over ygg with 64K mtu
zzz
I thought udp didn't work over ygg
orignal
can be tranferred a lot
orignal
it worked but bad
orignal
seems working now
zzz
or there was no point to udp over ygg
zzz
even if it did work
orignal
both
orignal
no point and didn't work well
zzz
but sure, we could make special rules for ygg
orignal
NTCP2 was easier
zzz
no objections
orignal
but 64K datagram can give bunch of profit
orignal
but it's later
orignal
64K frames for NTCP2 works well
zzz
yup
zzz
agreed
zzz
if you need me for SSU2 testing, mornings or early afternoon will be best
zzz
zlatinb, I also need to follow up with you this week on my RTT/ack delay simulations and testing
orignal
not now
orignal
I will let you know
zzz
anything else for the meeting?
zzz
thanks everybody, happy testing