GitLab

The tor spec says the following (section "2. Connections"):

In either case, once the responder has sent its certificate or certificates, the initiator counts them. If two certificates have been sent, it proceeds as in "certificates up-front"; otherwise, it proceeds as in "renegotiation" or "in-protocol".

and

To decide whether to do "renegotiation" or "in-protocol", the initiator checks whether the responder's initial certificate matches the criteria listed above.

and

All new relay implementations of the Tor protocol MUST support backwards-compatible renegotiation

Since the initiator can be a client or relay, I take this to mean that relays must allow V1 and V2 handshakes if the responder does not support a higher handshake version.

The tor code removed initiator support for V1 and V2 handshakes in legacy/trac#11150 (moved) for clients and relays. Since the official tor implementation does not support these handshakes for initiators, I don't see a reason to keep it in the spec. It also makes the code difficult to follow, and I've been confused looking at the code trying to understand how the initiators respond to these handshakes (assuming they did since it's in the spec), but it wasn't until finding the ticket above that I learned that it's been removed. So I think removing this requirement from the tor spec removes this discrepancy between tor and tor-spec, and also generally makes things more clear.