[tor-dev] Deprecating Tor Protocol Versions

[David Goulet]

On 15 May (13:58:06), teor wrote:
> Hi all,
> 
> Nick and I were talking about how we remove legacy features in tor,
> and their corresponding subprotocol versions.
> 
> Here is a list of the current subprotocol versions:
> https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2049
> 
> Here's a recent protocol version proposal, which deals with
> recommending and requiring new features:
> https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-removal-policy.txt
> 
> But we don't have a similar proposal for removing support for older
> protocol versions from the tor codebase.
> 
> For an example of what that proposal could look like, see our proposal
> for deprecating consensus methods:
> https://gitweb.torproject.org/torspec.git/tree/proposals/290-deprecate-consensus-methods.txt
> 
> Here's the original conversation Nick and I had:
> https://github.com/torproject/tor/pull/1874#discussion_r423713579
> 
> But after reading our consensus methods deprecation proposal, I've
> changed my mind. I think that we should check for "protocol N, and
> any later version" by default.

I agree that this is the right approach imo as well.

> 
> That's what we do for consensus methods, and it seems to work well.
> We can drop the earliest consensus methods, and recent tor versions
> just keep working.
> 
> If we need an incompatible change, we can make it another protocol
> version, and recommend then require support for it.
> 
> So here's an edited version of my notes on that ticket:
> 
> There are a few instances of ">=" and "=" confusion in protocol
> versions. We should try to fix them all.
> 
> It only matters when we remove protocol versions. We haven't
> really specified, tested, or exercised this functionality in
> practice. And so our reviewers lack experience. (And when we did
> discover a need for it with NSS and LinkAuth, it was more complicated
> than we expected.)
> 
> I'd like to see a proposal that tells us how to check future protocol
> versions as they are added. Along with a migration plan for disabling
> protocol versions.
> 
> So let's also open a ticket to check for "any future version".
> We should replace all "=" checks with ">=". Let's make sure we check
> all the places where we use protocol versions, even if they don't
> have a summary flag.
> 
> Overall, I think it would be helpful if future protocol versions were
> orthogonal. Or if they depend on earlier features, that dependency
> should be clearly documented. (For example, Relay=3 IPv6 extends
> depends on Relay=2 EXTEND2 cells. So if we were checking EXTEND2 cell
> support, it would be Relay=2 or Relay=3.)

At the moment, they do depend between each other last time I had that
discussion with Nick. As in the later in your example.

Which means that supporting protocol version with a ">=" is consistent with
our "non-written expectations" that we have now.

So if I understand correctly, we'll need to add a new protocol version let say
N+1 in order to deprecate anything <= N ?

As an example, Relay=4 could mean "deprecate Relay=2 and use only Relay=3"

I'm +1 on this if iiuc.

Cheers!
David

-- 
dApigzB8NtOQEAlKqhqbshxjxOMakjiX9LGU9wvhFqs=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200515/79a97542/attachment.sig>