[tor-bugs] #23010 [Core Tor/Tor]: prop224: make sure the protocol handshakes are extensible

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#23010: prop224: make sure the protocol handshakes are extensible
------------------------------+--------------------------------
     Reporter:  teor          |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: 0.3.2.x-final
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:  prop224
Actual Points:                |  Parent ID:
       Points:  2             |   Reviewer:
      Sponsor:                |
------------------------------+--------------------------------
 How and when do we plan to move away from using SHA1 in Tor circuits?

 For non-onion service circuits, this would mean:
 * implementing support for circuit digests using a secure hash [0]
 * adding a Relay protocol version 3
 * teaching clients to use a secure hash [0] digest with relays with Relay
 protocol >= 3

 For onion service circuits, it's more complicated, because the
 following circuit types can't use relay versions from the consensus:
 * client to intro
 * service to rend
 * client to service
 (Using relay versions from the consensus leaks which consensus clients
 and services have, which reduces the anonymity set.)

 Here are the upgrade mechanisms in prop224 at the moment, for both
 circuit protocol versions and any necessary handshake material:

 client to intro:
 * the protocol version could be in a proto line to each intro point,
  but this isn't implemented yet
 * the handshake data can be in the link-specifiers (I think?)

 service to rend
 * the protocol version could be in the EXT_FIELD in the INTRODUCE
  cell, but this isn't implemented yet
 * the handshake data can be in the link-specifiers (I think?)

 client to service:
 * the protocol version is in the create2-formats in the descriptor
 * the handshake data is in HANDSHAKE_INFO in the RENDEZVOUS cells
 * SHA3-256 digests are implemented, but not documented in prop224 (#22995)

 I suggest we make the following changes to prop224 to make this happen:

 Protocol version information:
 * add the relevant relay protocol versions to the intro point section
  of the descriptor
 * put the relevant relay protocol versions in an EXT_FIELD in the
  INTRODUCE cell
 * check create2-formats contains all the version info we will need to
  change the client to service circuit protocol version

 Downgrade resistance:
 * teach clients and services to use the highest common protocol between
  client/service and relay, excluding protocols that are below the
  minimum required protocol versions
 * work out how we will tell clients to no longer accept an old
  create2-formats line from a service

 [0]: probably SHA3-256, but let's make sure it can be upgraded, because it
 will be broken some day, too

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23010>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs