18. A peer sends only what you can prove you may read
A handshake binds a key to the session and read tickets must be for that key, so a peer sends nothing outside their areas; a middle box that swaps keys has no ticket for its own key and gets nothing.

18. A peer sends only what you can prove you may read

A handshake binds a key to the session and read tickets must be for that key, so a peer sends nothing outside their areas; a middle box that swaps keys has no ticket for its own key and gets nothing.

It is where capabilities meet the wire.

Every sync session starts with a handshake. Each side proves it holds its key, and the link is encrypted.

To receive entries, you show a read ticket. Its holder must be the key you just proved. Like a doorman who checks the ticket, and the face it was issued to.

A peer never sends data outside the areas your tickets cover. Not even to say it exists.

A peer can even make a fresh key pair for one session. It delegates itself a ticket for that key, and throws both away after.

A box in the middle can swap keys in the handshake. But then it needs a ticket for its own key, and it has none. It gets no entries and no names.

Check yourself. Why must a read ticket's holder match the handshake key?

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime

Collaborators