Discuss - 0009-MPID-Messaging about rfcs HOT 2 OPEN

It just occurred to me that we aren't encrypting the message itself and I am wondering if that shouldn't be happening. I know the possibility of an intercept is low but just considering that the message will be hold in memory by some rounting nodes, anyone on that node can then read that message – or am I mistaken here?. So you just need to gain access to enough Nodes/strategic Nodes and you could intercept information reliably

Maybe I am missing something obvious, but wouldn't it be better to encrypt the metadata and body with the recipients public key (which would also mean that you mathematically can't more than one recipient) before signing and sending only the encrypted content? Or do we guarantee in some other way that intercepted messages can't be read?

from rfcs.

I am not sure, if this is the right place, but I'll just leave this here then.

First off. Great work! I am happy you are discussing a new, safe way of secured message passing for the safe network. As a seasoned software dev, I think one major misappropriation was naming the programming model "Object Oriented" rather than "MessagePassingActors". A key infrastructure of any distributed system focus on independent actors which pass messages from and two each other. I love that you are also adopting this concept inside the actual infrastructure allowing to build cool apps on top, which can just rely on it!

First a general remark, which might just be a clarification of understanding on my side: MPID-Messages are supposed to be held in-memory by Manager Vaults (suggested here )? What if the vault the Node is on dies? Or am I missing something about how messages like these are stored in general? Also, how is an Inbox bound to the sender and can the size-limit be enforced?

To the nitty gritty:

MpidHeader

pub struct MpidHeader {
    sender_name: XorName,
    guid: [u8; 16],
    metadata: Vec<u8>,
    signature: ::sodiumoxide::crypto::sign::Signature,
}

The sender field is hopefully self-explanatory. The guid allows the message to be uniquely identified, both by receivers and by the Manager Vaults which need to hold the messages in a map-like structure.

While the sender field is self-explanatory, the signature is not. What is it signing? According to the code found later it is executed as (I added an explaining sentence in #125 )

let encoded = Self::encode(&sender_name, &guid, &metadata);

But is the sender_name really needed in this signature? If you'd temper with that the public-key for the XorName wouldn't be valid for that message anymore, would it? Or can different XorNames have the same private+public-key-pair, so you could impersonate a different sender – in which case including it in the signature wouldn't actually prevent this from taking place though.

I am only arguing this because for the message itself we have the definition:

MpidMessage

pub struct MpidMessage {
    header: MpidHeader,
    recipient: XorName,
    body: Vec<u8>,
    recipient_and_body_signature: ::sodiumoxide::crypto::sign::Signature,
}

Which doesn't include the header in the signature but has a terribly long name (I'd totally vote for also shortening that to signature and just have a decent definition in the RFC), which for some reason does not include the header (or even the header signature).

Which leads to that awkward case that I could ask the outbox for a guid I have in my inbox, but the message stored on the MpidManager (I am thinking of an entity that might has been messed with), is serving me a different MpidMessage, with a different header than the header I have for more guid, containing a totally valid signature but all of the sudden is from a different sender, making the signature of the message also valid as it is checked against a different sender now. Which means that the responsibility of ensuring that the message is cryptographically the one the header specified lies with the client anyways.

Which would however be made much easier to verify if the signature was defined as let encoded = encode(&header.signature, &recipient, &body); as the client already has a validated header (with its signature) and can put that in that equation, thus preventing someone from tempering with the headers after they are send.

All this written now, I am wondering whether the guid is needed at all. If instead you used the full-message-signature as that key (so a header.signature = sign(sender_name, metadata);, message.signature = sign(header.signature, recipient body), wouldn't that suffice? This would identify the message even further than a random id by their entire content, and we don't show that guid ever anyways, do we?

The only "problem" would occur when the same message is send twice (or you could argue that this actually not a real-life problem and should be considered the same message or the sender should include a timestamp or sequence number in their timestamp – see my remark after).

The metadata field allows passing arbitrary user/app data. It must not exceed MAX_HEADER_METADATA_SIZE bytes.

While I like that the you can add further metadata, but arbitrary user/app data might be a little to grand, no? Especially considering that there is no other field specifying that this message is meant for a specific app (is that supposed to be a thing), which means that an app would have to parse all messages MAX-HEADER metadata for a specific pattern in that field and moreover the information that this message is for that app is taking space of the METADATA_SIZE it can use. Which strikes me as inconvenient, if not annoying.

I'd strongly argue for either another field that specifies the MESSAGE_TYPE (allowing apps to specify their own types) and for system-wide defined MESSAGE_TYPES have stronger defined metadata-structure (maybe something like HTTP's key-value-strings or Filetype MIME-Type headers), potentially even using a struct rather than a u8-vector. (Not sure how/if this can be done easily). How else would you be able to identify whether something is an email-like message, an Instant-Message-Type (do we try to distinguish those) or an app sending information to another app – which I assume we want to support, as Safecoin are mentioned about this later?

• Also, not exactly within the scope of this RFC, but related to it; MPID packets at the moment have no human-readable name. It would be more user-friendly to provide this functionality.

I'd argue this wouldn't always have to be the case, but falls into the metadata-part I mentioned earlier. I'd argue that an "email"-like system should have a title in the metadata already, while in the case of a safecoin or instant message that doesn't make any sense. However, If you want to put the pressure of having the message on the sender side, the header needs to provide all necessary information for the client (or better: Person in front of the computer) to make the decision to retrieve that message or not. While the sender is a good indicator, at least for email the title would be another important one. And I'd actually add some rudimentary system to identify the message type and know which other fields/structs to expect to help with this process. (I am also wondering why there is not timestamp in there... I feel that is a good information to have)

PlainData {
    name: mpid_message_name(mpid_message),
    value: serialise::(MpidMessageWrapper),
}

What is name? Does it reference the message.guid? It'd be good to define what that is or rename it if that is the same.

from rfcs.