runtimes/google/ipc/stream: Beginnings of VC handshaking.
Currently, VIF setup works as follows:
- Once the net.Conn (e.g. TCP connection) is established, both sides
send a HopSetup message to each other.
The HopSetup message contains the NaclBox public keys needed to
established a secure channel as well as version ranges supported
by each end.
This allows the two ends to establish the protocol version needed
to communicate.
VC setup is different:
- The initiator sends an OpenVC message.
- If the initiator knows the version ranges of the destination, then
it is able to determine the exact protocol version to use.
If it does not know this range (such as when the endpoint is
specified as a host:port), it *assumes* that the remote end
will understand the highest version supported by the initiator.
- Once a VC is established:
- A new flow is used to setup encryption parameters
(a TLS session is established on this flow)
- Once the TLS parameters have been established, another flow
is created for authentication (blessings are exchanged over this)
This VC setup has seemingly multiple disadvantages:
(1) When using version-less endpoints (like host:port), the initiator
makes an assumption and if that turns out to be incorrect (e.g.,
if the remote binary doesn not have support for the assumed version)
then the VC cannot be established.
This is particularly bad for the common use case of host:port - the
root mounttable. If a client that supports the version range
[4,8] attempts to speak with a root mounttable at host:port, then
it will assume that the mounttable can speak version 8. If the
mounttable speaks [4,7], then even though the two could have
communicated (using version 7), they will fail to!
(2) Way too many round trips: TLS establishment (is like 3?) and the
authentication protocol (0.5).
So, we work towards a setup more similar to the VIF:
(1) The initiator sends a SetupVC message along with a naclbox
public key
(2) The acceptor, upon receipt of this message knows exactly
what version to use and replies with a SetupVC message
of its own - that includes the receiver's version range
and its naclbox public key (and possibly also its blessings)
(3) After this roundtrip, the sender has all the information he
needs to establish an encrypted channel with the server and
can authenticate it.
(4) The sender then sends its blessings in response.
With this scheme, the initiator makes no assumptions about the protocol
version to use, at no cost since version information from the acceptor
can piggy back on the key exchange messages anyway. So, encryption
and authentication should occur in 1.5 round trips instead.
This is the high level idea/plan.
This particular commit only introduces the SetupVC message.
We may defer the full implementation of this scheme (including switching
to naclbox) to after the first release, but having this message support
in there seemed like a reasonable first step.
Change-Id: Ib5d1198f350e58339fc99cf2b40368aaa335c5bb
5 files changed
