#i2p-dev (irc2p) | 2.8.2-6

orignal i2pd's streams can't work through I2CP because now way to swicth tunnels

orignal *no

orignal that's what i2pd's streams rely on

zzz hey altonen I've been commenting on some of your github issues, let me know if I'm being too chatty and I'll stop

zzz I do have a couple of tunnel build questions

altonen no i appreciate, ty for taking the time to share your thoughts

zzz ok good

altonen one q i had for you from your ramble message though

zzz shoot

altonen >It also may not "look" exactly like other routers, so it may be apparent that there's an emissary running on your IP

altonen did you mean this in terms of ISP figuring it out or others routers figuring out?

zzz other routers, particularly that it's NTCP2-only and with a certain router version

zzz this is for the people trying to stay anon that might show up here and say 'hey I'm testing emisarry and this happened'

altonen ok fair enough

altonen fwiw there are differences between java and i2pd as well to figure out which router a user is running

zzz if you want to push back on any of my warnings in ramble, please post a follow up, just trying to set expectations for the people that are really careful

zzz sure

zzz when there's a lot of emissaries out there it won't matter so much, but it's early days

altonen no it was reasonable, this was the v0.1.0 release after all

zzz as an example of some subtleties, can I ask a couple questions about tunnels/hop/pending?

altonen yes

zzz 1) I can't tell for sure, are you randomizing the tunnel build record order in the build request messages?

altonen not right now, i know they should be

zzz ok yeah, so hops don't know what hop they are

zzz 2) this one is more subtle, not sure how well documented:

zzz for IB, one of the fake records needs to have your router prefix in it, so the closest-hop doesn't know you built it

zzz this means for IB you need hops+1 build records because you must have a fake record for yourself

altonen definitely missing, didn't think of it, i'll add it to todo list

zzz great. if the specs are lacking about it let me know

zzz also don't forget changing the fake i2cp bw limits, happy to open an issue if you want me to

altonen i don't remmeber reading that but it's been many months since i went over the tunnel specs, could just be my memory

altonen it's on my todo list, just not on github yet

zzz ok, didn't know what you were using to stay organized ))

zzz one thing I may look at next is your handling of msgs rcvd down tunnels, that's where there's plenty of opportunity to get deanoned, and I don't think we offer much if any guidance

altonen ty! i await your findings

altonen btw why do ratchet reuse the old key, only or bob sends a new key and the other reuses the old key?

altonen *only alice or bob

zzz hmm. it's been a while.

zzz but iirc the two directions ratchet at different rates if the traffic is mostly one-way

altonen afair alice sends new key/reverse key request and needs to wait for a reply before ratchet, was just wondering why not bundle a new key to the reply

zzz tbh, ratchet is probably the protocol I'm least proud of, I think we made some questionable choices

zzz it was a huge amount of work and we were a little over our heads

zzz we have an opportunity to open it back up as we work on PQ ratchet but I'm reluctant

altonen what kind of choices?

zzz things like handshake retransmissions which are super-messy

zzz also we were clinging on to 0-RTT delivery of data in the session request, which we had in ElGamal, but that's not forward-secret

zzz so now here we are on PQ hybrid which is all about forward secrecy but should we still be doing 0-RTT?

zzz and if we're not going to do 0-RTT than why are we doing IK, maybe go back to XK. I hate IK.

altonen has it been measured how much worse the performance is w/o 0-rtt?

zzz no. it's just a first-reply latency hit

zzz the spec handwaves that if you want forward secrecy, just don't send data in the session request

zzz but I'm not sure how to make that work in my router, I've been thinking about it

zzz how to force through a ratchet handshake w/o data

altonen would be annoying to implement for me as well

altonen out of curiosity, what's the protocol you're most proud of if ratcet is atthe bottom of the list?

zzz some of i2pd's proposals assume or require a tight streaming/ratchet integration, but we have a strict separation with i2cp in-between; streaming knows nothing about ratchet, or tunnels, or anything router-side

altonen i ran into that i2pd design choice as well when testing

altonen but in the mainnet it works pretty well

zzz I think the last one we did, which is SSU2. It was last because it was the hardest, but we had all the experience, so it came out pretty well.

altonen right on

altonen i like the fact that it's easy to figure out to which connection a packet belongs to, i think it's well designed

zzz in terms of impact though, NTCP2 and SSU2 are just collections of minor tweaks and fixes and improvements.

zzz ratchet however was an enormous performance/security gain

zzz because the old ElG tagset stuff was bananas

altonen lol

altonen is ElG now getting killed with PQC?

orignal zzz, please tell about fake router prefix

orignal where do we put it?

orignal ELG is getting killed by ECIES not PQ

altonen ok

zzz orignal, at each hop, the hop can see the 16-byte hash prefix in the build record for the next hop

zzz if you don't put in a build record for yourself for IB builds, the last hop can see that there's no record for you, so he knows it's you

zzz so he knows it is IB and he's the last hop

zzz that's why we have 4 build records minimum

orignal last hop?

orignal one closest to me or IB?

orignal please clrify

zzz closest hop for IB only

orignal you mean 1 hops tunnel of what?

zzz any length. this is about the closest-hop deanoning you

orignal I don't understand how last hop knowns

orignal all other records are encrypted

orignal I'm the last hop before tunnel originator

orignal so in TBR I see the next hop's indent hash

orignal oh I see your point. thanks

zzz yeah the 16-byte hash prefix before the encrypted data

zzz do you do it?

orignal have to check. probably

orignal anyway I will teke cer

orignal e

orignal *care'

zzz ok

orignal I will be ready to test ML-KEM with you in couple days

orignal almost done

zzz great

orignal will run own test today to see if it works

zzz I guess altonen is now our ratchet expert

zzz we really need to think about if we want to change anything

zzz not sure I have the energy but maybe we should

orignal for PQ?

zzz yeah.

orignal up to you

orignal I have implemneted current proposal

zzz like do we want to keep 0-RTT, and if we don't, why not switch to XK

orignal if it need to be changed than fine

zzz not just up to me

orignal I prefer to keep using existsing ECIES

zzz me too

orignal one more MixKey is just fine for me

zzz but start making a list of things you don't like about ratchet, then we'll see

zzz XK or IK, doesn't matter, it's still one mixkey

orignal I'm fine with ratchets

orignal I told you before

zzz but PQ is about forward secrecy, so why are we doing 0-RTT which is not forward secret

orignal and can ask this question again

orignal why a session should even know remote destination

orignal for me it's mix of communication layers

orignal unless you want to restrict LeaseSets coming through it

orignal but you didn't give me definite answer

zzz we wrote all these specs together, I'm not the answer guy

orignal I knwo your reasons

orignal you asked me what I don't like

orignal about restricting LeaseSets do you think it's time to discuss?

zzz yes, it's messy

orignal so my proposal

zzz but all your ideas seem to require more mixing of layers

orignal only 2 kinds of leaesets are allowed in rathct block

orignal 1. reposnse to request

orignal 2. own leaseset

orignal all other leasesets should be dropped

orignal if you are talking aboyt streaming/datagram i2pd just dooesn't consider I2CP as another commujnication layer

orignal only like another client protocol

zzz I've never heard you worry about mixing layers before, I thought that was my thing and you didn't care

orignal about destinations in ratchets session I always had this concern

orignal i2pd just ignores this feild

orignal and fill it only for Java routers

zzz not sure what you mean

orignal github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/Garlic.cpp#L1013-L1018

orignal I consider "destination" delivery type as local

zzz oh, delivery type

orignal and I send "destination" only for Java

orignal I don't use it for communications

zzz well, that came from jrandom ofc. But the reason we kept it for ratchets is for multiple dests on the same tunnels

orignal I know why

zzz then that's your 'definitive answer'

orignal no, my qeustion is about LeaseSets

orignal we shouldn't accept any LeaseSets coming through a ratchets session

orignal the expected definite answer is if we can do it or I missed something

orignal e.g. can a session send LS on behalf of third party

zzz don't we do that for stores to ffs, and for lookups?

orignal I'm talking about sessions, not FFs

orignal e.g. between dests

orignal for lookup response no session just signle tag

zzz why? what's the threat model?

orignal an adversary can flood you with fake LSes

orignal if it can be any LS

zzz I think we have a limit somewhere to prevent that

orignal please tell me your limitations

zzz looking...

orignal unless it's juts trottling

orignal my idea is more ultimate

zzz 750 leasesets max

orignal might not be enough for a p2p

zzz sure, it's just a simple DoS prevention, nothing fancy