I like the proposal; what I think we now have to figure out, is what kind and how much of 'scanning resistance' to put into the tor binary.
If we assume that tor must act as something innocuous in the case of a false AUTHORIZE, we have to find out how much of that innocuous behavior should be implemented into tor. We probably want to avoid putting megabytes of innocuous-looking HTML pages or implement a bittorrent tracker into tor. Not only because the implementation will make the tor codebase even more bloated, but also because we would have to ship a new tor every time the censors manage to block an obfuscation.
What I think is saner - at least for the short term future - is find a couple of web services (not necessarily HTTP(S)) whose interface is easy to implement and have bridges stick to one of them at random, for as long as they stay on an IP address.
Some examples of such interfaces:
* A "HTTP server" whose index page is protected by HTTP basic access authentication. It's easy to code (a couple of HTTP headers and some HTML), with a small distinguishing surface and it also defends the fact that the same "web server" serves lots of data to other clients (read: the actual bridge users).
* A "HTTP server" whose index page is an Apache "It Works!". It serves 404s to any HTTP request.
* An "FTPS server" which asks for a username/password and obviously accepts none.
* An "SSH server" which asks for a username/password and obviously accepts none.
Then we can also add a torrc option, say "ScanningResistanceServicePort", that takes a local port as an argument and pipes all the input of the attacker (the person who failed the AUTHORIZE) to that port. In that port the user should have configured an actual web service which will handle that input.
In the future we can also code a project that pretends to be different web services for the sake of sitting behind "ScanningResistanceServicePort". That way we don't polute the tor codebase and we can also use high level programming languages.