Noise pipes and XXfallback

[AgeManning]

Am curious if there is work being done (or planned on being done) to update the current noise implementation for the 0-RTT with noise pipes as outlined in the specs: https://github.com/libp2p/specs/tree/master/noise

This is likely something we might build if no other work is currently being done on this. Asking to ensure we don't double up on efforts.

[tomaka]

Pinging @romanb, but I don't think anyone is working on this.

[romanb]

There is no work in progress at the moment that I'm aware of. For initial spec compliance I actually even wanted to drop IK and not support noise pipes, leaving only a few small changes to be done to names here and there, because I currently don't see a strong motivation for the added complexity in the context of the scheme of signing the static key with the identity key that is employed in libp2p. By the added complexity I mean the necessary caching (in-memory or even on disk) of static DH public keys as well as the entire fallback procedure from IK to XX. I personally like the simplicity of short-lived (e.g. lifetime of a process) static DH keypairs that are thus frequently rotated, since we already have the long-lived identity keys to keep (durably) safe.

That said, maybe I'm mistaken and the implementation complexity is less than I think and the benefits greater than I think, so in principal we are open to implementations of that part of the spec.

[AgeManning]

Awesome, thanks.

These are good points, I think having this optimisation is probably a lower priority for us then and maybe we'll get to it at some stage in the future.

Will likely leave it as is for now.

[tomaka]

Let's leave this open for later.

[burdges]

Noise 0-RTT still incurs key exchanges that ratchet forward the security, so you still need multiplexing via QUIC or whatever, and cannot pull connections up and down willy nilly.

[raulk]

Suggest closing this issue since the libp2p community has dropped IK and XXfalkback (Noise Pipes) from the spec. We should instead focus on doing the small adjustments that @romanb indicates to make rust-libp2p interoperable with the rest of the family. Any foreseeable plans for that?

[romanb]

@raulk That has already been done in #1545, just not released yet.