Re: [tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)

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

#28181: spec: Add to pt-spec.txt control messages going back to main process (tor)
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.6.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-spec, tor-pt, 036-roadmap-       |  Actual Points:
  subtask                                        |
Parent ID:  #28180                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by dcf):

 dgoulet posted some info here:
 https://lists.torproject.org/pipermail/tor-dev/2018-October/013512.html
 > Below is the link to the PT spec patch. It adds the EVENT message that
 for now is only used, as you will see, for reporting connection status
 message. However, you should see this EVENT message as extendable to
 whatever the PT would like to report to Tor that we can think of in the
 future:
 >
 https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket28181_01&id=0814114fb39f9f7ddf16de35f97092ed74ffd1ee

 > 3.3.4.1 `CONNECTION` type.
 > `CONNECTION <transport> <address> <port>`
 > `CONNECTION-ERROR <transport> <ErrorType> [<ErrorMessage>]`
 > `CONNECTION-SUCCESS <transport>`

 My concern with this design is that it only has in mind BridgeDB-like
 transports that work using a single connection to a single IP address. IMO
 it's already a misdesign that the `Bridge` line requires an IP address and
 port, forcing transport like meek to use a dummy address purely for
 syntactical reasons, which leads to other problems (#18611). Imagine a
 transport that works by tunneling through UDP DNS requests: what
 "connection" can you report? What IP address and port are you "connected"
 to, your local DNS resolver? Or what about a transport that muxes across
 multiple parallel TCP connections? IMO future transports are increasingly
 going to move away from the "one static host, one TCP connection" model.

 In the case of meek, there's no single connection nor specific IP address,
 because it's a sequence of HTTPS requests to a server identified by domain
 name. When a PT `PROXY` is in use, meek-client may not even know the IP
 address of the server. We could probably apply come logical hacks and try
 and fit messages into this reporting model, for instance by immediately
 reporting `CONNECTION meek 0.0.0.3 1` before even touching the network,
 then waiting for the first HTTPS request and reporting `CONNECTION-ERROR`
 if it fails and `CONNECTION-SUCCESS` if it succeeds. But what if the first
 HTTPS connection succeeds and the second fails (perhaps due to a temporary
 server 500 error)? We can't send `CONNECTION-ERROR` after sending
 `CONNECTION-SUCCESS`.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28181#comment:4>
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