General improvements to WakuRelay spec #316

jm-clius · 2021-04-01T14:34:07Z

This PR closes #266.

It adds improvements to the WakuRelay specification, including:

several clarifications of WakuRelay's relationship to libp2p GossipSub and the scope of each specification
corrections to Wire Specification, including how fields must be populated according to a StrictNoSign policy. This section should not be a review of PubSub, but a specification of WakuRelay's use of PubSub.
removed content that purely deals with how GossipSub works and has no bearing on WakuRelay and its goals
adding semantic line breaks according to https://sembr.org/. (Thanks for this suggestion, @D4nte. I think it will improve our specs if we use this as a best practice.)
general cleanup

staheri14

Nice set of clarifications and edits! well-done!

content/docs/rfcs/11/README.md

oskarth

Thanks for the clean up PR, looks good!

oskarth · 2021-04-02T04:01:47Z

content/docs/rfcs/11/README.md


-**Protocol identifier***: `/vac/waku/relay/2.0.0-beta2`
+`WakuRelay` specifies a [Publish/Subscribe approach](https://docs.libp2p.io/concepts/publish-subscribe/) to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability.


Instead if WakuRelay I'd call this 11/WAKU2-RELAY (ditto other parts of the spec)

Done in aeae2b5

oskarth · 2021-04-02T04:02:38Z

content/docs/rfcs/11/README.md


-**Protocol identifier***: `/vac/waku/relay/2.0.0-beta2`
+`WakuRelay` specifies a [Publish/Subscribe approach](https://docs.libp2p.io/concepts/publish-subscribe/) to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability.


I'd add all the unique links to a Reference section at the end, so we know what we are building on / make sure it is a canonical place / no dead links etc. No need for reference number though, just in addition to what exists now.

Done in aeae2b5

oskarth · 2021-04-02T04:03:31Z

content/docs/rfcs/11/README.md


 # Security Requirements

-The `WakuRelay` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model). Note that data confidentiality, integrity, and authenticity are currently considered out of the scope of the `WakuRelay` protocol and must be handled by the upper-level protocols such as [WakuMessage](https://github.com/vacp2p/specs/blob/master/specs/waku/v2/waku-message.md). 
+The `WakuRelay` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model).


Formatting - the spacing looks bigger than one newline but maybe this is just GH preview? (Same in other places, but doesn't look like newline or newspace)

Mmm, interesting. There's only a single LF-character each after lines 24 and 25. Think this may be a preview thing - there were double LFs elsewhere, which I've fixed in aeae2b5.

oskarth · 2021-04-02T04:03:43Z

content/docs/rfcs/11/README.md


 # Security Requirements

-The `WakuRelay` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model). Note that data confidentiality, integrity, and authenticity are currently considered out of the scope of the `WakuRelay` protocol and must be handled by the upper-level protocols such as [WakuMessage](https://github.com/vacp2p/specs/blob/master/specs/waku/v2/waku-message.md). 
+The `WakuRelay` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model).
+Note that data confidentiality, integrity, and authenticity are currently considered out of scope for the `WakuRelay` protocol and must be handled by higher layer protocols such as [WakuMessage](https://github.com/vacp2p/specs/blob/master/specs/waku/v2/waku-message.md).


Should link to rfc site url

I think @oskarth was able to use relative links in another PR.

Done in aeae2b5

oskarth · 2021-04-02T04:07:22Z

content/docs/rfcs/11/README.md


 ## Signature Policy

-The `StrictNoSign` option MUST be used. 
+The [`StrictNoSign` option](https://github.com/libp2p/specs/blob/master/pubsub/README.md#signature-policy-options) MUST be used, to ensure that messages are built without the `signature`, `key`, `from` and `seqno` fields. Note that this does not merely imply that these fields be empty, but that they MUST be _absent_ from the marshalled message.


What's the significance of this distinction?

There's a slight semantic difference between an empty field and an absent field in protobuf (an empty field will still have a populated field tag number when marshalled, which could lead to dodgy interpretations when unmarshalled). The latter is specified by PubSub for StrictNoSign, but repeated here as it may be an important implementation requirement for 11/WAKU2-RELAY.

content/docs/rfcs/11/README.md

oskarth · 2021-04-02T04:10:50Z

content/docs/rfcs/11/README.md

+Integrity and authenticity are typically addressed through digital signatures and Message Authentication Code (MAC) schemes, however, the usage of digital signatures (where each signature is bound to a particular peer) contradicts with the unlinkability requirement (messages signed under a certain signature key are verifiable by a verification key that is bound to a particular publisher).
+As such, integrity and authenticity are missing features in the `WakuRelay` protocol in the interest of unlinkability.
+In future work, advanced signature schemes like group signatures can be utilized to enable authenticity, integrity, and unlinkability simultaneously.
+In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members. <!-- TODO: shall I add a reference for group signatures?-->


 # Changelog


Given the simplification of lifecycle we could probably do away with this section. Draft means things can change, and once in stable it should only have cosmetic changes

Do you mean to move this content away from the "Future Work"-section or to remove this section completely, including the content?

Oh, wait. I realise now that you're probably referring to the Changelog section, not the Future Work section? 😀

Co-authored-by: Sanaz Taheri Boshrooyeh <35961250+staheri14@users.noreply.github.com>

content/docs/rfcs/11/README.md

D4nte · 2021-04-06T08:50:48Z

content/docs/rfcs/11/README.md


 # Security Requirements

-The `WakuRelay` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model). Note that data confidentiality, integrity, and authenticity are currently considered out of the scope of the `WakuRelay` protocol and must be handled by the upper-level protocols such as [WakuMessage](https://github.com/vacp2p/specs/blob/master/specs/waku/v2/waku-message.md). 
+The `WakuRelay` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model).
+Note that data confidentiality, integrity, and authenticity are currently considered out of scope for the `WakuRelay` protocol and must be handled by higher layer protocols such as [WakuMessage](https://github.com/vacp2p/specs/blob/master/specs/waku/v2/waku-message.md).


I think @oskarth was able to use relative links in another PR.

D4nte · 2021-04-06T08:52:34Z

content/docs/rfcs/11/README.md


 ## Signature Policy

-The `StrictNoSign` option MUST be used. 
+The [`StrictNoSign` option](https://github.com/libp2p/specs/blob/master/pubsub/README.md#signature-policy-options) MUST be used, to ensure that messages are built without the `signature`, `key`, `from` and `seqno` fields. Note that this does not merely imply that these fields be empty, but that they MUST be _absent_ from the marshalled message.


Co-authored-by: Sanaz Taheri Boshrooyeh <35961250+staheri14@users.noreply.github.com>

…lay-improvements

General improvements to WakuRelay spec

063874d

jm-clius requested review from D4nte, oskarth and staheri14 April 1, 2021 14:34

staheri14 approved these changes Apr 1, 2021

View reviewed changes

content/docs/rfcs/11/README.md Outdated Show resolved Hide resolved

oskarth approved these changes Apr 2, 2021

View reviewed changes

Update content/docs/rfcs/11/README.md

5749d39

Co-authored-by: Sanaz Taheri Boshrooyeh <35961250+staheri14@users.noreply.github.com>

D4nte reviewed Apr 6, 2021

View reviewed changes

jm-clius and others added 3 commits April 6, 2021 10:53

Update content/docs/rfcs/11/README.md

44918f0

Co-authored-by: Sanaz Taheri Boshrooyeh <35961250+staheri14@users.noreply.github.com>

Further improvements to 11/WAKU2-RELAY

aeae2b5

Merge remote-tracking branch 'origin/master' into improvement/waku-re…

5e0003f

…lay-improvements

jm-clius merged commit 608b04a into master Apr 6, 2021

jm-clius deleted the improvement/waku-relay-improvements branch April 6, 2021 15:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

General improvements to WakuRelay spec #316

General improvements to WakuRelay spec #316

jm-clius commented Apr 1, 2021

staheri14 left a comment

oskarth left a comment

oskarth Apr 2, 2021

jm-clius Apr 6, 2021

oskarth Apr 2, 2021

jm-clius Apr 6, 2021

oskarth Apr 2, 2021

jm-clius Apr 6, 2021

oskarth Apr 2, 2021

D4nte Apr 6, 2021

jm-clius Apr 6, 2021

oskarth Apr 2, 2021

D4nte Apr 6, 2021

jm-clius Apr 6, 2021

oskarth Apr 2, 2021

jm-clius Apr 6, 2021

jm-clius Apr 6, 2021

oskarth Apr 7, 2021

D4nte Apr 6, 2021

D4nte Apr 6, 2021


		Protocol identifier*: `/vac/waku/relay/2.0.0-beta2`
		`WakuRelay` specifies a [Publish/Subscribe approach](https://docs.libp2p.io/concepts/publish-subscribe/) to peer-to-peer messaging with a strong focus on privacy, censorship-resistance, security and scalability.

General improvements to WakuRelay spec #316

General improvements to WakuRelay spec #316

Conversation

jm-clius commented Apr 1, 2021

staheri14 left a comment

Choose a reason for hiding this comment

oskarth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment