What is the mechanism to agree on what CSID to use?
bachp opened this issue · comments
The documentation states that always the highest common CSID is used.
But it's not clear to me how this works. The hashname itself doesn't contain any information about the supported CS. So I guess the sender and receiver need to exchange some message first that contains a list off all supported keys.
I think this can not be part of the handshake as it only contains the highest CSID key.
So what am I missing?
Only one CSID's bytes are sent in the handshake but any other IDs are also sent as an intermediate hash so that the hashname can be calculate.
The recipient can then always sort and see the highest CSID key from the sender, and pick whichever highest one they also support.
Would definitely like to make this so simple to understand, suggestions welcome!
If there is an edge case where an initiator knows one public key, but not the other intermediate digests, the initiator still can't validate the hashname, so shouldn't send a handshake, even though it could?
Most of the questions I have boil down to: what goes in the BODY of a peer when there isn't enough information to create a handshake?
If I'm reading correctly, the initiator would create an un-encrypted handshake for every CS it supports, and use that for the BODY in multiple peer channels to the chosen router. The router would then forward each one as a connect channel?
If there is an edge case where an initiator knows one public key, but not the other intermediate digests, the initiator still can't validate the hashname, so shouldn't send a handshake, even though it could?
I think what you're saying is that a handshake cannot be generated unless the initiator can validate the recipient hashname first, and if so I completely agree, that is a fundamental requirement to generate a handshake.
Most of the questions I have boil down to: what goes in the BODY of a peer when there isn't enough information to create a handshake?
As you described it is currently correct, when using a peer and the initiator doesn't know anything about the hashname, it can't generate a handshake and has to send it all of it's keys so that the recipient can respond to the correct one (if it wants to). The router does know which one will work and can optionally drop the invalid ones, but that's just an optimization.
That help?
So trying to make sure @bachp's question is answered...
- A node only needs to choose a cipher set when creating a handshake. 2) Creating a handshake can't happen without knowledge of all remotely supported cipher sets. 3) Take a set intersection of (local, remote) cipher sets, and choose the highest number.
Situations where the initiating node has all this information (such as via a URI for the remote) are common. Situations where the node doesn't have enough information to create a handshake are handled by peer channels (which could use clarification via #128).
I think this may be clearer in the recent updates, but if not let's re-open this :)