add extension room in furls

[Brian Warner]

Zooko pointed out that we would benefit in the long run by adding some extension-tolerance into the current release of foolscap. Specifically, there are certain places in the FURL that could be extended in the future if we were to make the next release ignore the extensions:

• tubid: allow use of other hash algorithms, by extending the definition of the tubid field.
  • for 0.2.6, we declare that we'll read the first 32 characters of the tubid, assert that they are valid base32 characters, treat them as a tubid, and ignore the rest of the string
  • in the future, we can allow the tubid to be a comma-separated list of tubid hashes, and we can declare a format like 'sha256d.abcdef' to indicate the use of a different hash. When we actually start implementing this, we need to be careful to not open up protocol-rollback attacks or other vulneratibilities that result from two different versions of the code interpreting the string differently. In particular, the client should probably assert that all given hashes match, rather than just a single one.
  • during a transition period, host which wish their FURLs to be useable by 0.2.6 clients (and also want to provide better security for newer clients) must make sure to put the undecorated sha1 hash first.

• connection hints: allow the use of other protocols, by adding elements to the connection hints
  • split the connection hints field on commas, then look for anything that matches host:port, i.e. ^([^:]+):(\d+)$ . Ignore anything that doesn't match this.
  • I'd like to accept IPv6 addresses too, which means if the leading character is [, then expect to see ]:(\d+)$ .
  • In the future, we can add host:port:protocol, and trigger on the presence of three colons. Or, we could do protocol:host:port, but that is slightly harder to distinguish.
    • Zooko is interested in alternative protocols with fewer roundtrips, and possibly UDP based instead of TCP. For example, if the tub had an ECDSA public key (perhaps instead of the tubid), then we could use a ":udp" protocol that encrypts the method name and arguments and performs the entire request in a single roundtrip (with suitable replay protection, which might require the maintenance of some local persistent state).

In general, I'm not completely convinced that useful changes can be made within the limits that we establish on the format now, but from what I can tell we don't lose or risk anything by making these changes now.

[Brian Warner]

done, in [d783b77ce43ccf828ffce899755707f1688ea327]