Opened 5 years ago

Closed 4 years ago

Last modified 3 years ago

#12442 closed enhancement (worksforme)

Bridges should put their "transport" lines in their main descriptor, not extra-info desc

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-bridge, maybe-proposal, bridgedb-parsers 026-triaged-1 026-deferrable
Cc: karsten, isis, sysrqb, asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Bridgedb finds it a real hassle to paw through all the extrainfo descs, and match them up and check signatures and so on, just to know what ports and capabilities a given bridge is advertising.

Here's an example transport line from an extra-info desc:
transport obfs3 24.38.24.35:10872

Since the transport is a capability, rather than a statistic, I think it should go in the main descriptor, like where our or-address line goes.

Another benefit here is that clients will be able to learn what other transports their bridge supports, since they fetch and have its descriptor anyway.

The only drawback I see is that it's a bit less secret what your transports are. But I think the extrainfo descriptor is served to anybody who asks for it, so it's not a secret now anyway from people who can fetch your main descriptor.

Another option is to start putting the transport line in *both* places for a while, so people who parse these things (e.g. Karsten) have more time to transition. Seems better just to identify all the people who parse these things, get them to prepare for it, and then just move the transport lines.

Then in the distant future, places like bridgedb can stop needing the extrainfo descriptors too.

Child Tickets

Change History (13)

comment:1 Changed 5 years ago by isis

Keywords: bridgedb-parsers added

comment:2 in reply to:  description ; Changed 5 years ago by karsten

Replying to arma:

The only drawback I see is that it's a bit less secret what your transports are. But I think the extrainfo descriptor is served to anybody who asks for it, so it's not a secret now anyway from people who can fetch your main descriptor.

I thought the bridge authority doesn't give out extra-info descriptors:

https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/directory.c#l2847

  if (!strcmpstart(url,"/tor/server/") ||
      (!options->BridgeAuthoritativeDir &&
       !options->BridgeRelay && !strcmpstart(url,"/tor/extra/"))) {
    /* ... */
  }

Just saying. I don't feel strongly about whether additional transport lines should be kept secret from the users of a bridge. Something for the PT people to decide.

Another option is to start putting the transport line in *both* places for a while, so people who parse these things (e.g. Karsten) have more time to transition. Seems better just to identify all the people who parse these things, get them to prepare for it, and then just move the transport lines.

The only place where I'm handling these lines is in CollecTor when sanitizing bridge descriptors. I'd appreciate a heads-up of, say, 72 hours before the bridge authority starts accepting server descriptors with transport lines. For example, let me know when the patch is merged but before we ask Lucky to upgrade Tonga. Thanks!

Including transport lines in both server and extra-info descriptors is not necessary, IMO. Feel free to ask on tor-dev@ if anybody else uses these lines.

Then in the distant future, places like bridgedb can stop needing the extrainfo descriptors too.

Making things simpler is always a good plan.

comment:3 Changed 5 years ago by atagar

Including transport lines in both server and extra-info descriptors is not necessary, IMO. Feel free to ask on tor-dev@ if anybody else uses these lines.

I agree that it's not necessary to duplicate the line, but should be proceeded by a tor-dev@ notice. The transport line is an optional value in extra-info descriptors, so if it simply starts being omitted then the only risk is that someone else (not me or Karsten) read it and start thinking that transports don't exist any more.

Out of curiosity does this mean bridges will need to fetch server descriptors rather than microdescriptors?

comment:4 in reply to:  3 ; Changed 5 years ago by karsten

Replying to atagar:

Out of curiosity does this mean bridges will need to fetch server descriptors rather than microdescriptors?

Bridges never fetched microdescriptors but always server descriptors. The bridge authority does not even generate microdescriptors for bridges. It's a relay-only thing.

Also noting down here that atagar and I agree that @type bridge-server-descriptor in sanitized bridge server descriptors should be raised from 1.0 to 1.1 once these descriptors include sanitized transport lines.

comment:5 in reply to:  2 ; Changed 5 years ago by arma

Replying to karsten:

I thought the bridge authority doesn't give out extra-info descriptors:

Huh. Also it looks like bridge relays don't answer such requests either. So yes, this would be a new avenue for getting this transport information.

comment:6 Changed 5 years ago by nickm

Keywords: 026-triaged-1 026-deferrable added

comment:7 in reply to:  4 Changed 5 years ago by isis

Replying to karsten:

Replying to atagar:

Out of curiosity does this mean bridges will need to fetch server descriptors rather than microdescriptors?

Bridges never fetched microdescriptors but always server descriptors. The bridge authority does not even generate microdescriptors for bridges. It's a relay-only thing.


Right. They do have networkstatus documents, however.

Also noting down here that atagar and I agree that @type bridge-server-descriptor in sanitized bridge server descriptors should be raised from 1.0 to 1.1 once these descriptors include sanitized transport lines.


Agreed as well.

comment:8 in reply to:  5 Changed 5 years ago by isis

Replying to arma:

Replying to karsten:

I thought the bridge authority doesn't give out extra-info descriptors:

Huh. Also it looks like bridge relays don't answer such requests either. So yes, this would be a new avenue for getting this transport information.


This seems less of a problem currently, as most of the deployed transports are susceptible to active probing. However, in the future, when less active-probing susceptible transports become more widely deployed, it would benefit these newer transports to keep them hidden in the bridge extrainfo descriptors.

comment:9 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???
15:32 < nickm> isis, karsten: did y'all reach consensus on #12442 ?  I'm hoping 
               to implement or defer.
15:32 < nickm> Actually, I'll defer, and you can put it back in if you think 
               it's smart.

comment:10 Changed 4 years ago by isis

Given that we're increasingly switching to PTs which are resistant to active-probing, perhaps we don't want to implement this (unless we also want to make @type bridge-extrainfo descriptors more or less unobtainable).

Should I close this?

comment:11 Changed 4 years ago by isis

Resolution: worksforme
Status: newclosed

Closing this because I no longer feel it's a good idea, for the reasons mentioned above.

comment:12 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 3 years ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.