zzz
0) Hi
zzz
hi
orignal
hi
zzz
what's on the agenda for today?
orignal
SSu2
zzz
ok that's 1)
zzz
2) is I owe you an answer on NTCP2 clock skew
orignal
yes
orignal
and 3. frequent disconnects here
zzz
ping zlatinb
eyedeekay
Oh it all just showed up at once for me. Hi
zzz
ok disconnects is 3) but I think we may want to postpone that to a separate meeting
zzz
1) SSU2
zlatinb
I'm here
orignal
no problem we don't need to discuss 3
zzz
I haven't done anything on SSU2, been working on other things. I promised to do the header protection keys KDF
orignal
yes
zzz
hopefully will get to that soon
orignal
I start coding handshakes
zzz
nice
zzz
anybody have anything else to report about SSU2?
eyedeekay
Nothing here
orignal
not too much
zzz
ok. apologies for not getting to the header keys, will let you know when I do
orignal
no problem. I'm not at that stage yet anyway
zzz
yeah, I just want to keep things moving forward
zzz
2) NTCP2 clock skew
orignal
yes
zzz
our code is a mess and confusing
zzz
took me a while
orignal
how do I handle it properly?
zzz
but I think as Bob we usually just disconnect
zzz
after message 1
orignal
e.g. I receive SessionRequest with wrong timestamp
orignal
yes that's the problem
zzz
but there's two tests, one after msg 1 and one after msg 3.
orignal
say I'm Alice with clock skew
zzz
the msg 3 test is a little tighter.
orignal
but Bob just disconnects me and I don't know about my clock skew
orignal
please tell me
zzz
So sometimes, msg 1 passes, and then after msg 3, bob will send a destroy message with reason code 7
orignal
what Bib should do after 1 and after 3?
zzz
but that's usually only if the skew is 60 or 61 seconds
zzz
and as alice, will always disconnect after msg 2
orignal
what's the threshold for 1 and for 3?
zzz
+/- 60 seconds
orignal
then what's a difference?
zzz
or maybe 61 seconds for msg 1, 60 seconds for msg 3
zzz
there's some rounding
orignal
what just 1 second?
orignal
*why
zzz
looks like a bug to me
zzz
like I was in the middle of deciding what to do, and I left both sets of code in
orignal
then why do you even need to check after 3?
zzz
also, I didn't find any guidance in proposal 111 on what we should do
orignal
what is 111?
zzz
NTCP2
zzz
so, if you want to be nice, you go through the whole handshake and then send a destroy
zzz
if you don't want to be nice, just disconnect after message 1
orignal
or
orignal
send msg 2 and discoonect
orignal
it will let Alice know about troubles
zzz
it looks like I couldn't decide and I left both parts of the code in
zzz
but there's no place to put a reason code in msg 2.
orignal
you don;t need a reason
orignal
you send your own ts in 2
zzz
then how does alice know?
orignal
alice receives SessionCreated
orignal
find clock skew
orignal
in it
zzz
oh, the timestamp, yes
orignal
and since connectiin is closed she knows the reason is clock skew
zzz
you're +/- 30 or 60 right now?
orignal
let me check
orignal
const int NTCP2_CLOCK_SKEW = 60; // in seconds
zzz
I'm still not 100% sure I even understand what my code is doing
orignal
mine just closes connection
zzz
may have to do some testing
zzz
either way I also ban the peer for a while, so even if alice fixes the clock, she won't be able to connect
zzz
I think
orignal
that's not right
zzz
maybe not
zzz
that's all the info I have right now, I'll do some experiments and logging
orignal
so back to original question
orignal
how can we detect own closk skew
zzz
if we send back msg 2, that would do it. There's also SSU
orignal
yes
orignal
so should we?
zzz
we feed all the times from all the peers into our clock calculation
zzz
and we will set our clock from the first peer we connect to
orignal
if we can
orignal
and we can't in case of NTCP2 now
zzz
we always prefer SSU at startup
zzz
so we can do reachability tests
orignal
me too
zzz
and get introducers if we need it
orignal
well I detect clock skew
orignal
but don't adjust time
zzz
so I don't think it's a big problem
orignal
will try to fix
zzz
but sure, message 2 would be good, and I need to make sure I understand my own code (((
orignal
so I change Bob's code
orignal
always send msg 2 if clock skew
orignal
and then close connection
zzz
yeah, although if the same alice keeps trying, you'll need to ban anyway to not spend all your time doing DH
zzz
let's put it on the agenda for next week, hopefully I'll be smarter
zzz
anything else on 2) ?
orignal
DH in NTCP2 is nothing
orignal
no
orignal
about 3. looks it started happening after postman got his services back
Irc2PGuest47872
meeting over
R4SAS
heh
R4SAS
we was netspltted
eyedeekay
Yeah that was inopportune
R4SAS
19:58:27 <~zzz> anything else on 2) ?
R4SAS
19:58:59 <+orignal> DH in NTCP2 is nothing
eyedeekay
I don't think I have anything to add, but if one has to block based on skew how long does that have to last? It doesn't seem like it would necessarily need to be that long
R4SAS
19:59:04 <+orignal> no
R4SAS
20:03:17 <+orignal> about 3. looks it started happening after postman got his services back
R4SAS
at same time I asked on ilita:
R4SAS
20:02:07 <~R4SAS> zzz: I didn't see 1.6.0 and 1.6.1 tag on GH
eyedeekay
Tags are there now
R4SAS
huh, t/o-ed me
eyedeekay
The if the sync script ever encounters an error it pushes branches before it pushes the tags, so every once in a while they get out of sync, if that happens I just rerun that step
eyedeekay
Or wait for the cron job to do it
eyedeekay
Script seems to be working when I run it myself, weird that it would be broken that long when running in the background...
zzz
eyedeekay, that's why docker never updated, which I noticed but never bothered to mention to anybody :(
zzz
oh well, 8 weeks later...
eyedeekay
That's my bad, I run the sync script, I'll get it going on a second machine and make it do some retrying, maybe log where it fails for a change...
zzz
might also trigger some of the other downstreams like *BSD, who know
eyedeekay
Right now all I get is a flood of pretty non-descriptive cron mail
eyedeekay
Which is my fault, I wrote the script
zzz
lol