Add security negotiation protocol draft

[bigs]

Forgot to throw this up yesterday. Definite work in progress! Please take a look.

[Stebalien]

We should not do this:

1. We should not make a special-purpose protocol for negotiating security transports. We should use a general-purpose protocol negotiation protocol, ideally multistream.
2. We should not negotiate the security protocol, in general. We currently do this but this is vulnerable to downgrade attacks. Instead, we should include the security protocol in the multiaddr and then sign peer routing records.

[bigs]

@Stebalien sounds reasonable. @raulk mentioned it might be worth separating each part of packet orientation, so this was an effort towards that end. the multiaddr concept sounds most useful and the good news is this protocol is pretty much general enough to adapt towards protocol mixing

[bigs]

I do think the packet oriented case is sufficiently different from the stream oriented case to warrant a separate protocol, however, as it’s going to be married to the concept of mixing protocols over a single transport as well.

[raulk]

Have a look at the multiselect 2.0 design doc — we are assuming security schemes will be advertised in the multiaddr.

@bigs — what I suggested was to disentangle the whole message orientation story into separate threads (security, protocol indication/negotiation, chunking, ordering, etc.) to encourage a structured discussion. I don’t expect each thing to require a separate protocol.

Re: security, I think you should rely on inlined public keys (e.g. ed25519) as a hard requirement, and multiaddr advertisement. Using DTLS or Noise. For Noise you can pick the IK handshake and make the libp2p host key == Noise static key.

[bigs]

thanks for the feedback all. definitely glad to get a draft up early 😊

@Stebalien @raulk next steps will be to evolve the SECURITY.md document to detail the expectations (after closely studying multistream 2). then i will spin off a single, authoritative protocol for protocol selection and session management in packet oriented protocols using ideas from multistream and my prior work at camp. i think a draft of the evolved document can be ready this week

[raulk]

@bigs multiselect 2 tries to be as little interactive as possible — either because it has prior information about services supported by the peer, or because it tries to be optimistic. I think you could evaluate if multiselect 2 itself works for you, and if it seems like a fair construction, either advocate for message-orientation-specific concerns to be met within ms2, or if that’s unfeasible, consider a specialised variant on top of it. We definitely want to avoid reinventing the wheel, when a few adaptions could get us where we want to be.