handshakes

Handshakes are formal rules governing how two parties can commit to a mutual decision. They occur between a sender (the party initiating the handshake) and a receiver (the other party).

Handshakes are commonly used by humans for mutual decision-making (such as datetime and location for a meeting) and between computing devices to agree on communications parameters (such as transfer rate, protocol version, compression or encryption).

Handshake rules can be distinguished by the number of steps necessary for commitment to a mutual decision.

Three-way handshakes

Three-way handshakes imply commitment if (and only if) the sender proposes something, the receiver replies affirmatively and the sender confirms the receiver's reply.

  1. sender proposes proposition .
  2. receiver agrees to proposition .
  3. sender confirms that sender and receiver agree to proposition .
three-way handshake template

According to Paul Graham, Silicon Valley runs on handshake deals – verbal commitment before legal documents are created and signed.

  1. The investor says "I'm in for < offer > ."
  2. The startup says "Ok, you're in for < offer > ."
  3. The startup sends the investor an email or text message saying "This is to confirm you're in for < offer > ."
  4. The investor replies yes.
Paul Graham's Handshake Deal Protocol (step 2 and 3 combined correspond to step 2 of the three-way handshake template )

Computers on a network that set up connections using TCP follow the three-way handshake template, proposition consisting of a number.

  1. sender sends SYN message containing a number x
  2. receiver sends SYN-ACK message containing x +1 and a number y
  3. sender sends ACK message containing y +1
TCP three-way handshake

This construction is vulnerable to an attack in which a sender sends a large amount of SYN messages and no ACK messages ( SYN flooding), which leads to the receiver wasting resources waiting for ACK messages. A common defense mechanism ( SYN cookies) encodes handshake state in y , then discards y and tries to reconstruct handshake state from y +1 received in ACK messages.

Two-way handshakes

Two-way handshakes imply commitment to a proposition if (and only if) the sender proposes something and the receiver replies affirmatively.

  1. sender proposes proposition .
  2. receiver agrees to proposition .
two-way handshake template

Computers on a network that retrieve resources via HTTP and negotiate content details such as language or format ( HTTP content negotiation) follow the two-way handshake template.

  1. sender sends GET message requesting resource containing header Accept-Language: de (requesting resource in German language)
  2. receiver sends message containing either German language variant of resource or status code 406 Not Acceptable (if receiver is unable to provide German language variant of resource )
HTTP content negotiation

Negotiation success is not defined by sender and receiver agreeing on a proposition, but by both agreeing if they agree on a proposition. Agreeing to disagree is among the possible outcomes of a successful two-way handshake.

  1. sender asks May I kiss you?
  2. receiver replies Yes, kiss me! .
  3. sender and receiver kiss.
two-way handshake negotiation success, agree to agree
  1. sender asks May I kiss you?
  2. receiver replies No, don't kiss me! .
  3. sender and receiver do not kiss.
two-way handshake negotiation success, agree to disagree

Two-way handshakes can be used safely if (and only if) misunderstandings and messages loss are impossible (like with simple yes or no questions) or if misunderstandings or messages loss only lead to harmless outcomes (likely inaction on part of one or both participants).

  1. sender asks May I kiss you?
  2. receiver replies Lrf, xvff zr! .
  3. sender asks for clarification.
two way handshake negotiation failure, harmless outcome

One-Way handshakes

One-way handshakes imply commitment if the receiver does not reply. The sender expects the receiver to either silently consent or noticeably disagree.

  1. sender proposes proposition .
one-way handshake template

One-way handshakes can be used safely if (and only if) the receiver is capable to disagree and both misunderstandings or messages loss are impossible or if receiver disagreeing or misunderstandings and message loss only lead to harmless outcomes (likely inaction on part of the receiver).

  1. sender proposes Let us meet at your place at ! .
  2. sender comes over, finds receiver not at home.
  3. sender goes away.
one-way handshake negotiation failure, harmless outcome

Using one-way handshakes in situations where inaction on part of the receiver causes harm to the sender enables the sender to cause harm to themself and blame it on the receiver.

  1. sender proposes Let us meet at my place at ! .
  2. sender waits, receiver does not come over.
  3. sender is upset with receiver .
one-way handshake negotiation failure, harmful outcome

Handshake mismatches

A two-way handshake can not be distinguished from a partial three-way handshake by observing the messages of sender and receiver. Similarly, a one-way handshake can not be distinguished from a partial two-way or three-way handshake by observing the message of the sender.

  1. sender proposes proposition .
  2. receiver agrees to proposition .
two-way handshake or partial three-way handshake

Sender and receiver therefore must both know the handshaking mechanism before negotiation takes place. Since they cannot negotiate, the handshake mechanism has to be decided by one party, who then prepends the chosen handshaking mechanism to its first message.