encrypt handshake

[rade]

We should consider encrypting the handshake, perhaps with a key derived from the password via some suitable KDF. This was suggested in HackerNews.
#82 presents one use case. Another is that it allows us to populate the handshake with more information without needing to be concerned about its potential value to an attacker.

Finally, this closes off some possible attack vectors against the handshake, such as #912 (though note that simply encrypting the handshake is not enough to solve that one; the framing needs to change).

[dpw]

Why do we need some special encryption for the handshake? The only things actually required to set up the usual encryption for the TCP connection are the other end's public key and the version negotiation.
The key pair is randomly generated. Having version negotiation unencrypted doesn't seem like a big risk (TLS is plagued by downgrade attacks, but that is due to its long history and rampant parameterization, so I don't think the same concerns apply to weave).

[rade]

Why do we need some special encryption for the handshake?

Well, that's the topic of the discussion in that HN thread :)

[dpw]

HN-driven development.

[rade]

quite :)

[rade]

Well, it would be good to avoid multi-phase handshakes. So if we want to permit arbitrary, potentially sensitive, information in the handshake, then it needs to be encrypted.

[dpw]

Maybe I'm misunderstanding, but you think that avoiding a round trip when establishing a TCP connection is worth having some special encryption scheme for the handshake?

[rade]

Perhaps, yes.

[dpw]

How about we do the simple thing first, and elaborate it when a user tells us "hey, it would be really great if weave took a few milliseconds less to establish an encrypted connection"?

[rade]

How about we do the simple thing first

Fair enough. Remind me, what problem are we trying to solve with that? #912? #82? Or something else?

[dpw]

Well, the problem I'd really like to solve is to be able to add to the information exchanged when a connection is established without worrying about whether it is sensitive.

Yes on #912: given what will need to change, it looks like it can be addressed for free (the public key is a fixed length blob, so sending it pre-gob is easy).

No on #82: I think this will address the "to prevent spoofing" part of that issue, but there is a bunch of other work needed there.

[rade]

@dpw I believe you are working on this. -> assigning