gossipsub v1.1: introduce message signing policy

[protolambda]

See libp2p/go-libp2p-pubsub#359 for motivation and related discussion.

In short: Eth2 uses content-addressing and does not use these fields. If not content-addressed, signature data should be verified more strictly.

Changes:

• Pubsub readme:
  • Describe the optionality of singing in the relevant signing section of pubsub, and refer to new gossipsub v1.1 configuration option
  • Clarify that signatures are singing over all fields (incl unrecognized fields)
• Gossipsub v1.1:
  • Briefly describe the general two cases when the fields are desired or not.
  • Document legacy "lax" behavior may be implemented as additional signing policies
  • Document two main (strict) signing policies
    • Feedback wanted: best way to describe the rejection of messages with bad signature or unexpected/missing fields?

Out of scope:

• We had a related discussion about rejecting unrecognized protobuf fields altogether, to avoid any unexpected privacy issues or encoding edge cases. (will open an issue for this)

See ethereum/consensus-specs#1981 for Eth2 progress on this work, and clients implementing this functionality in gossipsub implementations.

PS. This is my first contribution directly to the libp2p specs, let me know if you have feedback to details such as formatting, I am happy to make changes.

cc @raulk, implemented the spec changes, review/edits welcome.

[arnetheduck]

this is problematic because protobuf is non-deterministic in its marshalling - the way to write this specification would be to remove mentions of protobuf and instead explicitly outline the marshalling in terms of key-value pairs and field types - it would have to be done carefully such that the result is readable by a compliant protobuf parser - it might also happen by chance that some protobuf encoders produce a valid byte stream, but with unrecognised fields in particular, the likelihood is low.

[raulk]

Let's hoist the protobuf deterministic serialisation discussion to a new issue.

[raulk]

It's been recurrent enough that it needs to be a first-class discussion with a solid outcome.

[vyzo]

I think we should specify canonical encoding here to remove all ambiguity.

[raulk]

Few comments; I'm going to take the liberty to push to your branch to make a few editorial changes, if you don't mind.

[raulk]

Mind elaborating what does content-based messages means here?

[raulk]

I think the two paragraphs that follow are better expressed as a bullet. Why don't we introduce the Lax modes here too? We anyway restrict all of this to v1.1, so we might as well introduce all options here.

[protolambda]

Should have called it content-addressed, or maybe you can think of better wording, to describe messages that identify themselves without the author, seqnoi and signature approach, like in eth2. These messages do not need to be signed, as for these it depends on the application layer, which checks contents etc.

[raulk]

I think the content-addressed and author-addressed word choice might be a bit confusing. How about "anonymous" and "origin-stamped"?

[protolambda]

That would work as well, maybe worth a short definition somewhere, it may pop up in other places of the pubsub spec as well. E.g. the message-ID customization may refer to the difference.

[raulk]

"origin-stamping" option.

[raulk]

Move this paragraph below the specification of both options. Otherwise we're speaking about v1.0, then v1.1, then v1.0 support in v1.1, back to v1.1.

[protolambda]

Sounds good, can you include this in the changes you wanted to make? I'm including this line mostly for awareness of backwards compatibility options, but it does not need to be part of the spec otherwise.

[raulk]

Separate these in two sub-bullets. "On the message producer side:" / "On the message receiver side:"

[arnetheduck]

One important point to raise here is that one reason to use gossipsub and not a custom protocol is that it's a generic message transport - we can expect that the gossipsub networks will cross-pollinate - say between ipfs and eth2 for example - and it's plausible that one might wish to be a participant of both. In fact, it's one of the main advantages of using gossipsub: peer diversity is increased.

The strict policies here somewhat limit that benefit - it creates, in effect, two different networks. The issue could be mitigated by making sure that implementations support different policies per topic - the way to achieve this would be to move some of the validation up to the application layer which easier can handle the per-topic nuances and instead only have a lax mode in gossipsub where:

• iff a field is present, it must be valid for its type
  • seqno must be 8 bytes
  • public keys and peerid's must parse as valid for their type
  • signatures, if present, must validate according to rules that will be lifted to a different PR
• iff the field is not present, gossipsub doesn't care per se - the application might though.
• this is congruent with the fields being optional in the protobuf description of the messages

on top of that policy, applications could then choose to restrict things further within the topic namespace they occupy - ie ETH2 might choose to not propagate messages with gossipsub signatures on eth2 topics (because we already do a mostly equivalent check / validation by verifying a payload signature).

Status is developing a similar protocol on top of gossipsub that also doesn't use the gossipsub signatures (because we negotiate a different scheme which is more appropriate for the status use case - the gossipsub signatures themselves live at the wrong level of abstraction which is why their usefulness is limited, often)

[djrtwo]

In fact, it's one of the main advantages of using gossipsub: peer diversity is increased.

Is this one of the main benefits? That is a clear benefit of using a cross-pollinated DHT but nodes of different networks are not going to generally subscribe to (or be able to execute validations of) gossipsub topics on an alternate network.

[arnetheduck]

well, I'd say so, yes - we're paying the protobuf tax, the "optional-seqno-and-signature-tax", we namespace the topics etc in order to achieve this interoperability where multiple applications can share the infrastructure - and it's not so much about validation specifically but alternatives that might have different needs but still be related (L2, a future ETC fork, client extensions etc).

If it was only ETH2, a much simpler thing to do would have been to take the research behind gossipsub, even forking it, and run it as a separate libp2p protocol (eth2sub/1.0.0) that would use SSZ and pure content-hashing - content-hashing is already a fairly significant departure from "standard" gossipsub - allowing per-topic optionality in the gossipsub fields in a way achieves the same goal but in a softer, more enabling way - ie it's still possible to create a restricted software where only a certain topic space with specific validations rules are applied, but it's also possible to create a mixed network with different rules applied to separate namespaces, without polluting the libp2p spec with application details.

[raulk]

I think @arnetheduck makes a valid point. If we make these signing policies configurable at the entire gossipsub stack level, it's no longer possible to participate in pubsub topics that adopt different signing policies. That is, you could never have a single node subscribed to both Filecoin (lax) and Eth2 (strict no sign) topics, which does harm interoperability and sabotages the feasibility of very desirable cross-chain applications and use cases.

I'm inclined to not merge this PR and iterate on the implementation submitted in libp2p/go-libp2p-pubsub#359 to push these options down to the topic level. That way, when you join to a topic, you specify the policy that applies to that topic.

@protolambda I know you are probably backlogged. Maybe someone in the libp2p or IPFS teams could take this on.

[protolambda]

@raulk pushing these options down to a topic level would be great, sounds like a good solution. And yes, quite backlogged with work. I think it is fair to add a notice in this PR that the options can be implemented on a per-topic basis. Then expand on that once the go-libp2p implementation has decided on the best approach.

[raulk]

@protolambda makes sense. I'll rejig the text, and add an implementation margin note that we can remove once this is pushed down to the topic level in go-libp2p.

[arnetheduck]

While working on this, we also noticed that this breaks the default message id generation, which relies on sequence number and peer id, is somewhat broken when the fields are not included - ie migrating fully to a content-based hash method when the anonymous mode is enabled is necessary.

[protolambda]

@arnetheduck yes, good point. And so message ID should be per-topic as well (it's kind of already, if you switch based on the topic info within the message). Will update PR now to incorporate formatting + per-topic behavior recommendation.

[protolambda]

@raulk update:

• Implemented your PR suggestions (or at least my interpretation of them, I wanted to clarify and format some more details).
• Added a section about message identification, and clarify the two common flavors, as well as moving the extra details from the fields section there.
• Message signature policy now states that it can initially be a global configuration, but per-topic policies facilitate mixed protocols better
• Optionality of fields is clarified, and states to depend on message ID and signature policy choices.

Again, feel free to make editorial choices, squash/rename commits, or any feedback. I would like to keep this PR moving, so we can continue with ethereum/consensus-specs#2060 before the next Eth2 specs release.

[raulk]

Apologies. Will get to this later today.

[raulk]

I'm not sure what the goal of this is. This might be better moved to after "Signature Policy Options", and put under a "Usage indications/notes" section.

I would reword to something like this:

• Origin-stamped messaging: choose StrictSign, and use in combination with the default message_id_fn.
• Content-addressed messaging: enable StrictNoSign, with a custom hash-based message_id_fn. Any signatures would now be part of the payload, and would need to be validated through a custom message validator.

[protolambda]

The idea was to give some context/intuition why the fields are handled like they are. It could be worded directly as message id approach -> signing policy directions, like you suggest. Either option works for us.

[raulk]

I'm going to commit my suggestions, and I'll do another pass tomorrow. Also requesting @vyzo's review here.

[vyzo]

Thank you, this is a very welcome addition.

However, I think that the signature policy should be part of the pubsub spec and not the gossipsub spec.
There is nothing gossipsub specific about signature policies, and the policy applies to all routing algorithms as signing is handled outside the router -- at least in the reference implementation.

[vyzo]

I think we should specify canonical encoding here to remove all ambiguity.

[vyzo]

I am not sure that this should be in the gossipsub spec -- it is a generic pubsub policy that applies to all routing algorithms.

[raulk]

Agreed, will move it.

[protolambda]

Was looking for a place to version it, but since it's not breaking anything necessarily, and applies to pubsub, moving it to the pubsub doc sounds good.