New RFC: 35/WAKU2-NOISE #496

s1fr0 · 2022-03-09T02:14:31Z

This PR addresses the first task of #494.

staheri14

Thanks @s1fr0, nicely done 👏 ! Please see my comments below.

content/docs/rfcs/35/README.md

staheri14 · 2022-03-10T00:13:21Z

btw, if the PR is ready for review, please mark it as such. It is currently tagged as a draft. @s1fr0

oskarth · 2022-03-10T05:28:29Z

content/docs/rfcs/35/README.md

@@ -49,10 +49,10 @@ The fields that are concatenated as part of the `payload` Waku2 field are:
 - `protocol-id`: identifies the protocol in use (1 byte). 
 Supported values are:
     - `0`: none or omitted;


Can we add the version for ChaChaPoly symmetric case only? So applications don't need to revert to previous version for this use case

oskarth · 2022-03-10T05:29:15Z

content/docs/rfcs/35/README.md

+- *Authenticity*: The adversary should not be able to cause a Waku2 endpoint to accept messages coming from an endpoint different than their original senders.
+- *Integrity*: The adversary should not be able to cause a Waku2 endpoint to accept data that has been tampered with.
+- *Identity-hiding*: A passive adversary should not be able to link encrypted messages to their corresponding senders and recipients.
+


PR should also update Waku Message v2 with a short description and link to this spec

staheri14 · 2022-03-10T23:25:51Z

@s1fr0 Please let me know whenever your updates are ready for review

s1fr0 · 2022-03-10T23:56:49Z

@staheri14 ready for a second round of review. I addressed all comments. Thanks!

oskarth

Nice one! Left some comments in-line

oskarth · 2022-03-11T05:41:13Z

content/docs/rfcs/35/README.md

+contributors: 
+---
+
+This specification describes how Waku2 messages can be encrypted


Suggested change

This specification describes how Waku2 messages can be encrypted

This specification describes how Waku Messages can be encrypted

Possibly with a link to tWaku message specs

Addressed in 8becd7b

oskarth · 2022-03-11T05:41:28Z

content/docs/rfcs/35/README.md

+
+This specification describes how Waku2 messages can be encrypted
+in order to achieve confidentiality, authenticity, and integrity 
+as well as some form of identity-hiding on communicating parties.


I'd mention forward secrecy here

I mentioned it slightly later.

oskarth · 2022-03-11T05:42:36Z

content/docs/rfcs/35/README.md

+
+Specifically, it describes how encryption keys can be exchanged using the [Noise protocol Framework](http://www.noiseprotocol.org/noise.html) 
+to allow authenticated encryption/decryption in [10/WAKU2](/spec/10) with [14/WAKU-MESSAGE version 2](/spec/14/#version2). 
+This ultimately allows Waku2 users to instantiate end-to-end encrypted communication channels.


I'd rephase as applications built on top of Waku to provide this

Addressed in 8becd7b

oskarth · 2022-03-11T05:43:39Z

content/docs/rfcs/35/README.md

+This ultimately allows Waku2 users to instantiate end-to-end encrypted communication channels.
+
+
+This specification is an addition to [26/WAKU-PAYLOAD](/spec/26).


...and its functionality provides a super set with modern primitives and stronger guarantees/more modular, such as x~

something like this

Can also add a sentence pointings to 5 Status secure spec saying it subsumes it too for applications interested in strong conversation security guarantees

Addressed in 8becd7b

oskarth · 2022-03-11T05:44:43Z

content/docs/rfcs/35/README.md

+## Design requirements
+
+- *Confidentiality*: 
+The adversary should not be able to learn what data is being sent from one Waku2 endpoint to one or several other Waku2 endpoints. 


"Waku2" is used throughout the text but doesn't refer to anything specific I think. Can probably replace with Waku if just want generic term here.

Addressed in 8becd7b

oskarth · 2022-03-11T05:45:35Z

content/docs/rfcs/35/README.md

+
+- *Confidentiality*: 
+The adversary should not be able to learn what data is being sent from one Waku2 endpoint to one or several other Waku2 endpoints. 
+In particular, forward secrecy should be provided on exchanged data. 


would it make sense to pull out forward secrecy as a separate point?

Addressed in 8becd7b

oskarth · 2022-03-11T05:47:07Z

content/docs/rfcs/35/README.md

+We refer to [Noise protocol framework specifications](http://www.noiseprotocol.org/noise.html#processing-rules) for the full details on how parties shared secret key is derived from each exchanged message.
+
+Four Noise handshakes are currently supported: `K1K1`, `XK1`, `XX`, `XXpsk0`
+(their description can be found [here](https://forum.vac.dev/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130)). 


I wouldn't refer to forum post in spec probably - either Noise spec or summarize in Appendix in this spec

Addressed in 8becd7b

oskarth · 2022-03-11T05:47:40Z

content/docs/rfcs/35/README.md

+Four Noise handshakes are currently supported: `K1K1`, `XK1`, `XX`, `XXpsk0`
+(their description can be found [here](https://forum.vac.dev/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130)). 
+These are instantiated combining the following cryptographic primitives:
+- [`Curve25519`](http://www.noiseprotocol.org/noise.html#the-25519-dh-functions) for Diffie-Hellman key-exchanges (32 bytes curve coordinates);


Would it make sense to have a section with cryptographic primitives like this e.g. https://rfc.vac.dev/spec/26/#cryptographic-primitives ?

Not sure. Right now the section is "Supported Cryptographic Protocols" and contains the details of both the primitives employed by Noise protocols and encryption primitives (since we separately support ChaChaPoly) within two separate subsection. If we have a new/separate section naming all primitives employed (noise + encryption), it would look like we can have a Curve25519 and/or SHA256 as separate primitives that can directly called/used to build waku message payloads, although, in fact, those are just the (only for now) combination of primitives used to instantiate supported Noise handshakes. If in the future add support to blake2, AES-GCM, Curve448, etc. then it may be better a separate subsection inside the current "Noise Protocols" subsection, so that users are aware of the different combinations supported for the tuple (curve, cipher, hash) (besides encryption primitives used as such, no matter the key exchange protocol).

oskarth · 2022-03-11T05:50:36Z

content/docs/rfcs/14/README.md

@@ -69,6 +69,13 @@ This provides for asymmetric and symmetric encryption.
 Key agreement is out of band.
 It also provides an encrypted signature and padding for some form of unlinkability.

+### Version 2
+
+This indicates that payloads MUST be encoded using [35/WAKU-NOISE envelope data format spec](/spec/35).


Suggested change

This indicates that payloads MUST be encoded using [35/WAKU-NOISE envelope data format spec](/spec/35).

This indicates that payloads MUST be encoded using [35/WAKU-NOISE](/spec/35).

Addressed in 8becd7b

s1fr0 · 2022-03-14T10:23:39Z

Addressed new comments

staheri14

Added some more comments

content/docs/rfcs/35/README.md

D4nte · 2022-03-15T03:43:12Z

content/docs/rfcs/35/README.md

+slug: 35
+title: 35/WAKU2-NOISE
+name: Noise Protocols for Waku Payload Encryption
+status: raw


Suggested change

status: raw

status: raw

tags: waku-core-protocol

Addressed in b587e8b

D4nte · 2022-03-15T03:43:55Z

content/docs/rfcs/35/README.md

+
+Specifically, it adds support to the [`ChaChaPoly`](https://www.ietf.org/rfc/rfc7539.txt) cipher for symmetric authenticated encryption. 
+It further describes how the [Noise Protocol Framework](http://www.noiseprotocol.org/noise.html) can be used to exchange cryptographic keys and encrypt/decrypt messages 
+in a way that that the latter are authenticated and protected by *strong forward secrecy*.


Suggested change

in a way that that the latter are authenticated and protected by *strong forward secrecy*.

in a way that the latter are authenticated and protected by *strong forward secrecy*.

Addressed in b587e8b

D4nte · 2022-03-15T03:44:26Z

content/docs/rfcs/35/README.md

+
+
+This ultimately allows Waku applications to instantiate end-to-end encrypted communication channels with strong conversational security guarantees,
+similarly as done by [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) but in a more modular way, 


Suggested change

similarly as done by [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) but in a more modular way,

as similarly done by [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) but in a more modular way,

Addressed in b587e8b

D4nte · 2022-03-15T03:49:12Z

content/docs/rfcs/35/README.md

+even in the case he has access to communicating parties' long-term private keys (during or after their communication).
+- *Authenticity*: the adversary should not be able to cause a Waku endpoint to accept messages coming from an endpoint different than their original senders.
+- *Integrity*: the adversary should not be able to cause a Waku endpoint to accept data that has been tampered with.
+- *Identity-hiding*: a passive adversary should not be able to link encrypted messages to their corresponding senders and recipients.


I am not sure this design requirements can fully be covered without providing guildelines on the content topic.
I agree that the content topic handling is out of this spec's scope, but I think we should highlight that poor content topic handling can compromising this requirement.

Now better addressed in 4076b1e

D4nte · 2022-03-15T03:54:39Z

content/docs/rfcs/35/README.md

+ - `transport-message-len-len`: the length in bytes of `transport-message-len` (1 byte);
+ - `transport-message-len`: the length in bytes of `transport-message` (`transport-message-len-len` bytes);
+ - `transport-message`: the transport message (`transport-message-len` bytes);
+ - `transport-message-ad`: the symmetric encryption authentication data for `transport-message` (16 bytes).


Suggested change

- `transport-message-ad`: the symmetric encryption authentication data for `transport-message` (16 bytes).

- `transport-message-auth`: the symmetric encryption authentication data for `transport-message` (16 bytes).

nitpick: I think auth would be easier to understand it stores the auth data than ad.

Addressed in b587e8b

D4nte · 2022-03-15T03:55:01Z

content/docs/rfcs/35/README.md

+; contains the size of handshake-message
+handshake-message-len       = 1OCTET
+
+; containes one or more Diffie-Hellman public keys


Suggested change

; containes one or more Diffie-Hellman public keys

; contains one or more Diffie-Hellman public keys

Addressed in b587e8b

D4nte · 2022-03-15T03:55:54Z

content/docs/rfcs/35/README.md

+    -  `transport-message` contains the Noise transport message;
+- `10`,`11`,`12`,`13`: payload encodes a supported Noise handshake message.  
+    -  `transport-message` contains the Noise transport message;
+- `30`: payload encapsulate a `ChaChaPoly` ciphertext `ct`.  


Suggested change

- `30`: payload encapsulate a `ChaChaPoly` ciphertext `ct`.

- `30`: payload encapsulate a `ChaChaPoly` ciphertext `cipher`.

IMHO, cipher is clearer than ct.

Not sure, cipher sounds more related to the cipher itself. ciphertext is definitely better although quite long. ct is common in crypto, but probably not clear enough here. I don't have a strong opinion on this though

D4nte · 2022-03-15T03:57:58Z

content/docs/rfcs/35/README.md

+to a multiple of the underlying symmetric cipher block size 
+(16 bytes for `ChaChaPoly`).
+
+It is therefore recommended to pad transport messages to a multiple of 256 bytes.


So transport-message should be right padded, correct?

Yes, this allows more efficient decryption, i.e. you may stop decrypting blocks when you observe a padding start (which might be part of the plaintext though). In the left pad, you need to decrypt everything (pad+message) to get the last byte of message.

Clarified in in b587e8b

D4nte · 2022-03-15T04:00:53Z

content/docs/rfcs/35/README.md

+parties SHOULD set `protocol-id` to `0` 
+to reduce metadata leakages and indicate that the message is an *after-handshake* message.
+
+It is recommended that each party attaches an (unencrypted) ephemeral key in `handshake-message` to every message sent.


We usually upper case the RFC-2119 terminology: https://rfc.vac.dev/spec/1/#language

nitpick: Active voice is usually easier to read than passive voice (if my grammar is correct)

Suggested change

It is recommended that each party attaches an (unencrypted) ephemeral key in `handshake-message` to every message sent.

Each party SHOULD attach an (unencrypted) ephemeral key in `handshake-message` to every message sent.

Addressed in b587e8b

D4nte · 2022-03-15T04:01:49Z

content/docs/rfcs/35/README.md

+## Backward Support for Symmetric/Asymmetric Encryption
+
+It is possible to have backward compatibility to symmetric/asymmetric encryption primitives from [26/WAKU-PAYLOAD](/spec/26), 
+effectively encapsulating  payload encryption [14/WAKU-MESSAGE version 1](/spec/14/#version1) in [version 2](/spec/14/#version2).


Suggested change

effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](/spec/14/#version1) in [version 2](/spec/14/#version2).

effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](/spec/14/#version1) in [version 2](/spec/14/#version2).

Addressed in b587e8b

staheri14

Thanks for addressing previous comments, please see my new comments below

content/docs/rfcs/35/README.md

staheri14 · 2022-03-15T21:42:27Z

content/docs/rfcs/35/README.md

+
+In all supported Noise protocols, 
+parties' static keys are transmitted encrypted, 
+while ephemeral keys MAY be encrypted after a handshake is complete.


If this is the case i.e., both ephemeral pks and static pks can be encrypted, how would you distinguish between these two in the current serialization pattern?
~~btw, which handshake pattern contains an encrypted ephemeral key? with a quick check I could not find~~. found my answer already :)

During an handshake, you don't need to distinguish, since the handshake pattern is pre-agreed (so you know the sequence of ephemeral-static encrypted/unencrypted keys). After handshake you'll only have ephemeral keys exchanged to refresh with new randomness encryption keys. The distinction between encrypted/unencrypted can be done simply looking at the authentication data.

If you know the order of pks by knowing the handshake pattern, then why do we need a flag to indicate encryption? isn't it also clear from the pattern?

Because in a handshake message you may have a concatenation of multiple public keys. Without a flag you may confuse authentication data with the next public key or waste bytes for an all-zero-empty authentication data in case you keep sizes fixed for all fields.

you may confuse authentication data with the next public key

Can you please give an example of such a situation? not numerically just symbolically

It is not impossible, only less structured.

For example, without flags
handskake-message = pk1 pk1-auth pk2 pk3
You read the first 32 bytes and you get pk1. You read next 16 bytes, if authenticating pk1, decrypt pk1. Otherwise continue reading next 16 bytes and store the last 32 bytes read as pk2, etc.

Probably hard to do, but you may generate a public key pk2 with MSB set to authentication data pk1-auth and confuse the implementation, although the handshake will simply fail.

Thanks for the explanation, isn't the presence of pk1_auth dictated by the handshake pattern? i.e., if there has been a shared key established prior to pk1, then an encrypted pk1 is expected? which means the next item in the handshake message should be pk1-auth?

If this comment of mine also requires further discussion, let's issue it up and resume our conversion there.

I would say both yes and no. The handshake is pre-agreed, so everyone knows what to expect. In after-handshake, although you may exchange only ephemeral keys for which there is no need to use encryption, you may encrypt them as well (for example to authenticate the ephemeral key itself, but again encryption will fail if you're cheating). I think the flag may be useful in the future for Noise pipes, i.e. while executing multiple handshakes in a row: you can indeed upgrade the whole handshake to a fully encrypted version, although you can then use a psk version of the handshake then.
It is also true that besides handshakes, I don't expect to exchange more than one public key during normal communication, so checking the length of handshake-message would suffice to understand if the public key is encrypted or not, and we can in fact remove the flag.

content/docs/rfcs/35/README.md

oskarth

Thanks! Minor comments. Seems good enough to me as a raw spec :)

For other issues in PR, I defer to Sanaz and other reviewers here in terms of what should be addressed in this PR.

I also expect some tweaks to happen as this moves closer to draft, so one option is also to pull out some of the outstanding options into a separate 'enhancement/fixup' issue.

oskarth · 2022-03-16T05:00:46Z

content/docs/rfcs/14/README.md

+This indicates that payloads MUST be encoded using [35/WAKU-NOISE](/spec/35).
+
+This provides key-exchanges and encryption based on [Noise Protocol](http://www.noiseprotocol.org/noise.html). 
+It also provides `ChaChaPoly` symmetric encryption.


In version 1 paragraph we say:

This provides for asymmetric and symmetric encryption. Key agreement is out of band. It also provides an encrypted signature and padding for some form of unlinkability.

Perhaps we can say high some similar high level stuff? So people who just glance at RFC 14 can get rough idea of why they want to use version 2 over version 1.

Addressed in 505e405
Shall we mention forward secrecy and unlinkability as well, or we just keep it very general as it is now?

staheri14

Nice one! LGTM!

staheri14 · 2022-03-17T23:11:23Z

@s1fr0 What is left on this PR to get merged?

s1fr0 · 2022-03-18T08:37:52Z

@staheri14 It is ready, just some minor pending discussions. But I will merge and eventually later PR minor changes.

s1fr0 · 2022-03-18T08:45:01Z

Should I change the left menu to allow users to find the spec? Can I directly commit to master or better to have a new PR?

staheri14 · 2022-03-18T20:57:30Z

Should I change the left menu to allow users to find the spec? Can I directly commit to master or better to have a new PR?

Right, that should be added to the menu, please create a new PR. @s1fr0

* master: RFC16: add version call (#505) fix(noise): update RFC to implementation (#508) fixup: 37/WAKU2-NOISE fix images paths (#506) New RFC: 37/WAKU2-NOISE-SESSIONS (#504) 36/WAKU2-BINDINGS-API (#501) docs(16/WAKU2-RPC): add ENR to waku info (#502) Adding 35/WAKU2-NOISE to menu (#500) add RFC33 to index (#499) feat: 32/RLN raw spec New RFC: 35/WAKU2-NOISE (#496) Update on the rln registration figure to match the current spec (#497) 33/WAKU-DISCV5: Add first raw version (#487) Add pubsubTopic field to index (#492) Fix markdown links (#493) Categorize 22 & 31 (#490) Changed PB Timestamp index to 10 (#491) 13/14/16/21: Change in timestamp format (#483) add: RFC31 copyright statement (#489) 17/WAKU-RLN-RELAY: Revise spec for its draft version (#484)

Create README.md

f1b415e

oskarth added this to New in vac-research Mar 9, 2022

oskarth moved this from New to Review/QA in vac-research Mar 9, 2022

s1fr0 linked an issue Mar 9, 2022 that may be closed by this pull request

Integrating key-exchange protocols in Waku2 #494

Closed

2 tasks

s1fr0 marked this pull request as draft March 9, 2022 02:17

s1fr0 requested review from staheri14 and oskarth March 9, 2022 02:17

oskarth requested review from D4nte, jm-clius and kaiserd March 9, 2022 07:14

s1fr0 added 2 commits March 9, 2022 09:38

Fixes typos

1d275bf

Update README.md

046331c

staheri14 reviewed Mar 10, 2022

View reviewed changes

oskarth reviewed Mar 10, 2022

View reviewed changes

Addressed comments

d9fd289

s1fr0 marked this pull request as ready for review March 10, 2022 23:15

Fixes

1130369

s1fr0 requested review from staheri14 and oskarth March 10, 2022 23:56

oskarth reviewed Mar 11, 2022

View reviewed changes

addressing comments

8becd7b

s1fr0 requested a review from oskarth March 14, 2022 10:23

staheri14 reviewed Mar 14, 2022

View reviewed changes

content/docs/rfcs/35/README.md Show resolved Hide resolved

content/docs/rfcs/35/README.md Show resolved Hide resolved

D4nte reviewed Mar 15, 2022

View reviewed changes

Addressed comments

b587e8b

staheri14 reviewed Mar 15, 2022

View reviewed changes

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

Addressed comments

4076b1e

staheri14 reviewed Mar 15, 2022

View reviewed changes

content/docs/rfcs/35/README.md Show resolved Hide resolved

staheri14 reviewed Mar 15, 2022

View reviewed changes

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

oskarth approved these changes Mar 16, 2022

View reviewed changes

staheri14 approved these changes Mar 16, 2022

View reviewed changes

Addressed comments

505e405

s1fr0 merged commit f03df03 into master Mar 18, 2022

s1fr0 deleted the waku2-noise branch March 18, 2022 08:41

vac-research automation moved this from Review/QA to Done Mar 18, 2022

s1fr0 mentioned this pull request Mar 20, 2022

Adding 35/WAKU2-NOISE to menu #500

Merged

s1fr0 added track:rfc-process RFC process track (RAD) track:waku-specs Waku specs track (RAD) and removed track:rfc-process RFC process track (RAD) labels Jul 27, 2022

	This specification describes how Waku2 messages can be encrypted
	This specification describes how Waku Messages can be encrypted

		This ultimately allows Waku2 users to instantiate end-to-end encrypted communication channels.


		This specification is an addition to [26/WAKU-PAYLOAD](/spec/26).

	This indicates that payloads MUST be encoded using [35/WAKU-NOISE envelope data format spec](/spec/35).
	This indicates that payloads MUST be encoded using [35/WAKU-NOISE](/spec/35).

	in a way that that the latter are authenticated and protected by strong forward secrecy.
	in a way that the latter are authenticated and protected by strong forward secrecy.



		This ultimately allows Waku applications to instantiate end-to-end encrypted communication channels with strong conversational security guarantees,
		similarly as done by [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) but in a more modular way,

	similarly as done by [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) but in a more modular way,
	as similarly done by [5/SECURE-TRANSPORT](https://specs.status.im/spec/5) but in a more modular way,

	- `transport-message-ad`: the symmetric encryption authentication data for `transport-message` (16 bytes).
	- `transport-message-auth`: the symmetric encryption authentication data for `transport-message` (16 bytes).

	; containes one or more Diffie-Hellman public keys
	; contains one or more Diffie-Hellman public keys

	- `30`: payload encapsulate a `ChaChaPoly` ciphertext `ct`.
	- `30`: payload encapsulate a `ChaChaPoly` ciphertext `cipher`.

	It is recommended that each party attaches an (unencrypted) ephemeral key in `handshake-message` to every message sent.
	Each party SHOULD attach an (unencrypted) ephemeral key in `handshake-message` to every message sent.

	effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](/spec/14/#version1) in [version 2](/spec/14/#version2).
	effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](/spec/14/#version1) in [version 2](/spec/14/#version2).

New RFC: 35/WAKU2-NOISE #496

New RFC: 35/WAKU2-NOISE #496

Conversation

s1fr0 commented Mar 9, 2022

staheri14 left a comment

Choose a reason for hiding this comment

staheri14 commented Mar 10, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 commented Mar 10, 2022

s1fr0 commented Mar 10, 2022

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

Choose a reason for hiding this comment

s1fr0 commented Mar 14, 2022

staheri14 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 left a comment

Choose a reason for hiding this comment

staheri14 Mar 15, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s1fr0 Mar 15, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s1fr0 Mar 15, 2022 • edited

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

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

staheri14 left a comment

Choose a reason for hiding this comment

staheri14 commented Mar 17, 2022

s1fr0 commented Mar 18, 2022 • edited

s1fr0 commented Mar 18, 2022

staheri14 commented Mar 18, 2022

staheri14 Mar 15, 2022 •

edited

s1fr0 Mar 15, 2022 •

edited

s1fr0 Mar 15, 2022 •

edited

s1fr0 commented Mar 18, 2022 •

edited