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

Connections0

Connections show where other documents or comments link to this document.

Related documents

Loading connections…