Re: Idle musings on doing E over again

On 10/3/12 12:59 PM, Mark S. Miller wrote:

> I think the lack of perfect forward secrecy is a significant issue. Is
> there a good way to provide it within this framework?

It can be done, but takes more work, and moves things back to being more
connection-oriented.

http://curvecp.org/ is worth studying. It's an encrypted replacement for
TCP (including forward-secrecy, flow-control, support for client
IP-address mobility, even hiding the client's long-term key from anyone
but the server), based on Curve25519. It requires a couple of round
trips to set up, and provides the usual byte pipe, so it's basically an
improved version of TLS.

You could get forward-secrecy without the connectionness of CurveCP by
having each side choose a short-term Curve25519 DH key, exchange them
under protection of a long-term Ed25519 signing key, then encrypt the
data with the derived session key. Every once in a while, one side picks
a new Curve25519 key, and starts using it (they must sign the "I'm using
a new key now" message with the long-term key). The two sides don't even
need to coordinate their changes.

The easy-but-noisy approach would include both sides short-term keys in
every message, along with long-term key's signature. Then you'd only
have to remember a sequence number. If a hundred bytes of overhead on
each message is too much, you could only send the keys when they change,
and have each side remember the most recent key in addition to the
sequence number.

The amount of forward-secrecy you get all comes down to when you choose
to forget the session key (and switch to a new one). With a
connection-oriented scheme, the loss of the connection is an obvious
place to forget things and thus protect the future (but even then, you
might want to speed up new connections by using some session-resumption
feature, and that loses the forward-secrecy, so it's not always
obvious). More sophisticated schemes will negotiate some sort of
periodic key rotation, so the "sessions" will be longer than a single
TCP connection but still not forever.

> Note that E's current VatTP has always provided perfect forward
> secrecy (thanks Bill and Tyler!) and there are std TLS cyphersuites
> that do as well.

Yup. The issue, as always, is how easy it'd be to get at the needed
functionality. Most TLS libraries are very CA-centric. If you were
designing a new protocol, I don't know if it'd be easier to A: include
the crypto in the code and tell implementors/porters to provide a
platform function to deliver the encrypted messages, or B: rely upon the
platform's TLS library and tell implementors to find a way to intercept
the cert-validation process correctly. If the crypto is small enough, I
suspect A is more likely to work out, but maybe I've just had too much
exposure to TLS libraries :).

cheers,
 -Brian