[noise] Socketguard: seeking feedback on protocol variations

[Trevor Perrin]

On Sat, Apr 18, 2020 at 10:21 AM Ben Burkert <ben at benburkert.com> wrote:
>
> Hello,
>
> I am working on a Linux module [1] for encrypting TCP traffic. It's
> similar to NoiseSocket, but more along the lines of "Wireguard for
> individual TCP connections". By building on the ULP feature in Linux,
> encryption can be setup in userspace and performed by the kernel without
> pulling in additional libraries, or implemented as a language library
> [2] for non Linux/ULP environments. The implementation mostly follows
> Wireguard's protocol for a Noise_IK handshake, but varies slightly from
> Wireguard & the Noise spec. I'm hoping to get some feedback on these
> variations from the Noise spec.
>
> First up, the version negotiation data is encrypted in the handshake
> messages for both the initiator and responder. Here the encrypted
> version data is constructed the same way as the initiator's encrypted
> static public key.  However, while the static public key is encrypted to
> provide identity hiding, the version is encrypted to prevent downgrade
> attacks and to "grease" the protocol.

Hi Ben,

If the version is encrypted it might be hard to use the version to
change things about the encryption.  If you want to encrypt some
negotiation data though, couldn't you just put it in the handshake
payload?


> Secondly, rekeying is modified to include an "es" DH exchange to provide
> ongoing forward-secrecy and key-compromise impersonation resistance.

If you've already got the ability to handshake, and a TCP connection,
just running the handshake again might be simpler.

Or you could just rely on Noise's "rekey" ability to ratchet the
encryption keys forward, so a compromise can't decrypt old data.


Trevor