@eyedeekay
&eche|on
&zzz
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+hottuna
+orignal
+postman
+weko
An0nm0n
Arch
FreefallHeavens
Gid
Hidenet
Irc2PGuest19856
Irc2PGuest24992
Irc2PGuest2827392
Irc2PGuest38157
Minogami
Onn4l7h
Onn4|7h
Palimpsest
ProRu
Sleepy
SoniEx2
T3s|4_
Teeed
aargh4
admin
anon
b3t4f4c3__
cheddah
eyedeekay_bnc
itsjustme
j6
limak
not_bob_afk
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
user
w8rabbit
x74a6
zer0bitz
mesh
zzz: According to geti2p.net/en/docs/discussions/naming the Destination Certificate is always null?
mesh
/win 3
zzz
mesh as it says at the top, that page is a historical document of alternatives, not current documentation
mesh
zzz: sorry. Not sure if I asked this before but it's not possible to customize the Certificate attached to Destinations right?
zzz
no, not possible, as it would conflict with current usage for sig types. A custom cert would force you to DSA-SHA1 which you don't want
mesh
zzz: is this something that might happen in the future? The more I think about it the more I think it would be really cool if we could learn about the remote peer and decide if we trust them just based on the Destination
zzz
its an interesting idea but as you can see we went in a different direction. I'm sure there's a way to encode both sig type and trust in a cert, but it would be a big chane
zzz
change
mesh
zzz: ok. It does seem similar functionality can be achieved using encrypted lease sets. I will look into those.
mesh
I think the basic goal is (1) the server can reject the client at ServerSocket.accept ... without actual communication and (2) possibly the client's Destination is "well known" to the server.
zzz
no, I don't think encrypted leasesets provides you with any trust info
zzz
LS2 does have room for arbitrary additional info
mesh
zzz: I thought with encrypted lease sets the client can only connect to the Destination if they have been given a privkey to decrypt the Destination?
zzz
but trust is something that's better handled out-of-band, not encoded into the identities themselves
zzz
sure but having an access key isn't quite the same as trust
zzz
see for example our subscription protocol that contains signatures - see also muwire - think also about X.509 certs for certificate authorities
zzz
all that is out-of-band processes for trust hierarchies
mesh
zzz: for an encrypted lease set all clients share the same access key, right?
zzz
for LS 1 yes, but that's deprecated. For LS2, there's options for both single key and per-client key
zzz
encrypted LS is not really about trust at all, but about hiding the LS contents from the ff
mesh
zzz: yeah, I'm starting to see that. Though per-client keys sounds interesting.
mesh
we can reject clients whose Destination isn't on a well-known Destination list but if you want to actually authenticate the client and determine who they are probably need some sort of challenge protocol
zzz
you're thinking too low-level when you're musing about protocols and implementation, and you're jumbling up issues of identity, authentication, security, and trust
zzz
start top-down, what system are you trying to design, what are the threat models, who are the authorities or trust anchors
zzz
some things you need may be natively provided by i2p, others you'll have to build on top of it
mesh
zzz: yeah I get that.We probably shouldn't rely on Destinations as meaningful identifiers anyways.
mesh
I can see lots of reasons why a client or server might change their Destinations but not their "identity"
mesh
whoa lag
zzz
suggest you take a look at Muwire and its "persona" concept
mesh
zzz: will do
mesh
zzz: github.com/zlatinb/muwire/blob/master/doc/web-of-trust.md does look interesting. I didn't realize you could use the signing key of the Destination to sign other stuff.
mesh
zzz: but I'm now probably going to go the other way. Like you said, it's not really I2P's concern
zzz
zlatinb is your resource for muwire, I'm not fluent in the details, but yes signing keys can be used for other things
mesh
instead of tying identity to an I2P Destination, introduce a separate concept. That way if a server comes under attack and it has to run away by changing its Destination it doesn't lose its entire identity.
dr|z3d
zzz: that record-setting connection on SSU2.. surprising?
zzz
no
dr|z3d
ok, was just curious if it exceeded currently expectations.
dr|z3d
*current
zzz
no, I expect it to work, but there's still more to do on acks and nacks
dr|z3d
oh, I didn't mean were you surprised that it worked, just curious if buffer sizes and queue lengths can be tweaked to improve throughput.
zzz
not at the tuning stage yet, but I got excellent bandwidth last time I tried it on the testnet
dr|z3d
ok, well, from the visibility I've got on it, seems to be working great.
zzz
baby steps
dr|z3d
:)