+R4SAS
+RN
+RN_
+Xeha
+acetone
+orignal
Irc2PGuest33667
Onn4l7h
T3s|4_
aargh2
cumlord
leopold_
mareki2p_
not_bob_afk
profetikla
shiver_
u5657
vvx2
x74a6
zzz
reminder: Proposal 163 second review today 7 PM UTC here
zzz
if you're here for the review, please say hi, even if you just plan to lurk
eyedeekay
hi
orignal
hi
altonen
hi
orignal
droad as usual ))
orignal
*drozd
zzz
ok. hello everybody, thanks for showing up
zzz
this is the 2nd review of proposal 163, datagram 2, first reviewed on March 4
zzz
I'll give a brief overview of what's changed, and then throw it open for comments
zzz
the main thing that changed was in response to a comment/request from orignal
zzz
to add a version with a hash only, and without a signature
orignal
yes, but we agreed it should be Datgarm 3
zzz
I called it 'datagram3' but I guess we could call them 2a and 2b, I don't care
zzz
in the proposal, I called it datagram3
zzz
so there's now two sections, one for datagram2 and one for datagram3, with separate pictures
zzz
that's the end of the summary, I'll throw it open for comments and questions
orignal
so, do you want me to explain how it should work without signature?
orignal
and still be a repliable datagram
zzz
well it is "repliable", it's just not authenticated
zzz
but go ahead
orignal
well it should authniticated
orignal
e.g. you are not supposed to just accept it
orignal
you need to verify it's identity too
zzz
at what layer, and how?
orignal
so, I presume that if it's repliable datagram you have LS to reply to alreadt
orignal
layer is another topic
orignal
so, I receive such datagram
orignal
extract ident hash
orignal
then find LS by this ident hash
orignal
from LS I extract static key and compare with one from ratchets session datagram came from
orignal
I'm thinking in i2pd categories
orignal
not sure if it's doable in I2CP
orignal
EOT
zzz
ok should I respond now or ask for comments from others first?
orignal
I think verification must be done on router's side
orignal
but we need to know content of Data message
orignal
I think others opinion
zzz
ok, dr|z3d eyedeekay altonen any comments or questions?
zzz
either on orignal's comments or on the proposal as a whole?
dr|z3d
sorry I joined late, nothing right now, just getting the flavor of the conversation.
orignal
but did you get my idea?
orignal
that we need to remeber session datargam came from
altonen
my q is: why would i use dgram2 if dgram3 has smaller overhead and sig is not needed?
dr|z3d
I probably missed the first half of it.
zzz
2 vs. 3 is an application choice
orignal
altonen because i2p still supports ElGamal
orignal
that's only reason I see
zzz
do you need authentication or not
altonen
ok fair enough
orignal
zzz, not only autenticaion
zzz
we also have an eye on PQ, where a dest + sig is much much MUCH larger than just a hash
orignal
you just can't pass full ident in case of PQ
orignal
because huge overhead
altonen
i don't know, orignal's argument makes sense to me if i can verify stuff using info from ratchhet
zzz
well, you can, it's just large
orignal
altonen the main concern is I2CP
zzz
well, let's assume for the moment that the router is not doing any verification. I think there's still a use case for Datagram 3
orignal
because they need to verify on client side
altonen
ok ty orignal
zzz
that's why I put datagram 3 into this proposal, because it's useful even without orignal's idea
zzz
maybe somebody uses it, maybe not, but it's easy enough to code up
dr|z3d
can someone explain the thrust of orignal's suggestion and why it's large?
zzz
but the security analysis of unauthenticated datagrams is really up to the application developers
orignal
why PQ ident is large? Becuase PQ keys length
dr|z3d
ok, I didn't get the part where we were talking about pq. thanks.
eyedeekay
I'm mulling over orignal's explanation but does reaching into ratchet to verify the message constitute a layering issue? Also, if the signature is verified using ratchet, I think the high-level description of how to do that should be part of the spec
zzz
a x25519 dest + sig is 433 bytes
zzz
a MLDSA44 dest + sig is 3739 bytes
eyedeekay
\/sig/ident/
dr|z3d
probably an obvious question, but if we need to peer into the packet to identify its contents in some way, can't we just add a flag in the header instead, and only handle the header?
zzz
no. a datagram2 is dest + payload + sig
zzz
ok lets get into it
orignal
let's hear you
zzz
I have two short answers and one long answer
zzz
short answer 1: write a proposal for it ))
zzz
short answer 2: I really don't see how we can do it with i2cp in the middle
orignal
how? easy
orignal
a router reads I2NP data message
orignal
then gzip header recognizes it's datagram
zzz
long answer: we'd have to gunzip every packet on the router side, peek in. Or, maybe, add something to I2CP for the router to tell the client something about the packet, if it was inside a session or not
orignal
verifies and pass some flag/option to client
orignal
like dr|z3d suggests
zzz
this is your idea, so write it up and convince us. I'm not doing all the research for you.
orignal
can we specify a session option that router is obliged to verify?
zzz
and it's related to, but independent of, this proposal
zzz
and I think your real idea is to use this to redesign streaming, so that turns into a big proposal
orignal
not really
orignal
let me explain
orignal
for streaming it's not so critical
orignal
because you send it only in SYN packet
orignal
while for datagram you must do it in every single packet
orignal
hence for streaming you can leave as it for not
orignal
*now
orignal
and not for datagrams
zzz
but that's not the way datagrams work in the real world, like snark DHT
dr|z3d
haha, orignal stealthing a streaming redesign. LOL.
orignal
how does it work in snark?
orignal
still repliable I guess
zzz
you send one signed datagram with a token. The other guy responds with a raw datagram with the token in it. YOu can both keep going with raw datagrams with the token
orignal
not raw
zzz
you never ever send a bunch of signed datagrams in a row
zzz
yes raw
orignal
it depends on your implemntation
zzz
right. the choice of signed/raw/2/3 is always up to the application design
orignal
agree
zzz
like with our old "streamr" UDP tunnel. You send ONE signed datagram to the audio server. He sends you a zillion raw datagrams, and you listen to your music
orignal
I send once in 100 ms
zzz
streamr was like every 10 seconds or 60 seconds or something, basically a 'subscribe' request
orignal
anyways
orignal
I think we should keep both 2 and 3
zzz
let me list some alternatives on how to finish this
orignal
dr|z3d I care more about PQ than streaming itself
zzz
1) approve as-is with 2 and 3
zzz
2) rip out 3, ask orignal to put it in his proposal, approve this proposal with 2 only
zzz
3) don't approve anything yet, wait for orignal's proposal
zzz
EOT
orignal
ha ha
orignal
you know about 2. and 3. already
zzz
well, the only way it's going to happen is if you do it, or you get somebody else to, and it's not going to be me, sorry
zzz
I would like to get datagram 2 approved so I can start work on snark UDP announces
zzz
but it's up to you guys
orignal
yes, datragram is fine for me
altonen
+1
zzz
please make clear what you're voting for, option 1) 2) or 3)
eyedeekay
I vote 1.
altonen
i'm fine with 1
dr|z3d
re gzip flags, this might be useful: mrbluyee.com/2024/03/25/zlib-and-gzip-format/#GZIP-header
zzz
and orignal, what's your vote?
orignal
fine
dr|z3d
seems like we have a quorum, then. everyone votes "1".
zzz
super. I'll get it moved into the specs
orignal
1
zzz
anything else on proposal 163?
dr|z3d
a quorum and a consensus. double chocolate.
zzz
next week (NOT in two weeks) is the second review of PQ
orignal
yes we have a lot to talk about PQ
zzz
yes
zzz
one thing I need help with, is research on what hash to use, stick with sha256 or switch
orignal
I vote stick with sha256
zzz
drz put an excellent link up in #saltr the other day, but that's just one guy's opinion (the guy who wrote it)
altonen
why are you considering a switch?
zzz
because now is the time if we want to
orignal
because someone suggested it ))
zzz
maybe we do, maybe not
zzz
the guy suggested it and then drz banned him, for what it's worth
altonen
lol
dr|z3d
in case you missed the link: kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3
altonen
ty
zzz
do we have any volunteers to actually do research and make a recommendation next week (not just throw out a vibes opinion) ???
zzz
maybe it's not doable in a week, which is fine, but can somebody step up for the research?
eyedeekay
I can make/bring a chart
zzz
charts are easy. I want to know whether THIS use case is vulnerable anytime soon.
zzz
is hashing in noise handshakes a concern for collision? preimage? 2nd preimage? in what timeframe?
orignal
especially since it's for mixhash only
zzz
note that this is NOT a PQ issue. sha256 is not vulnerable to PQ.
orignal
yes, it's noise
orignal
can we add another "MixHash" with different hash just for PQ round?
zzz
don't think that makes sense
zzz
still looking for a volunteer to research and report
zzz
hearing none, I'll ask again at the review next week
zzz
thanks everybody
eyedeekay
I can research sha2 attacks all week but I have serious doubts about my ability to narrow the focus to noise-specific issues
eyedeekay
Thanks zzz
orignal
I would like to disucss signatures
orignal
because it's next step
dr|z3d
some additional preliminary links for a different perspective from the one in the linked article above:
dr|z3d
> In summary, while SHA512 theoretically provides larger security margins than SHA256, both hash functions have demonstrated excellent collision resistance so far. For most applications today, SHA256 appears to offer sufficient security along with performance advantages. But SHA512 may prove beneficial where additional reassurance is needed considering future threats and cryptography advances.
dr|z3d
(from the last linked article)
zzz
ok, if nobody feels qualified to take the lead, then we'll all have to get smarter about it
zzz
this issue may delay things by up to several months, but shouldn't stop progress elsewhere
zzz
the collision resistance issue is, I assume, most relevant to our netdb, as it would catastrophically break things
zzz
whether it has any relevance to noise handshakes, dunno
altonen
could be relevant: eprint.iacr.org/2021/292.pdf
zzz
orignal, to clarify my 'gunzip every packet' comment:
zzz
I meant:
zzz
1) check every gzip header for protocol type
zzz
2) if it's datagram3, gunzip it to get the hash and verify it
zzz
eot
orignal
yes I know what it means
orignal
but, usually real gzip is nothing
orignal
jst memcpy