I wonder if it's worthwhile defining signing of state events

Would that be needed? This MSC outlines signing events in general, and that should also include state events already?

The title strongly implies this just signs messages. Also, you may want to add the state_key to the part that gets signed, similar to how the event type is handled.

It doesn't, because you do not include the state_key in the stripped content. You'd need to define that. (argh message races :|)

So like event_type + state_key + canonical_json, where if state_key is a blank string we have "normal" PDUs?

I guess one aspect is if that you banned person A state_key=@alice:example.com, and the server changed that to say state_key=@bob:example.com, it would look to others like you had banned bob.

If the server was clever enough to hide that fact from you somehow, it could look, at least for a bit, like you had done something malicious.

it would still be signed as state_key=@alice:example.com, so the signature would not match

don't get soru wrong, event type and state key are included in the signature as per this MSC, there is just no separater, so it is just event_type + state_key + canonical_json

Oh, right. Yes, I don't think you can really attack it. I defer to a spec team grey-beard on whether they want separators because I think it's mostly a style thing at this point.

even with separators you could always construct event types / state keys to mimic those.

Depends how you design the separators, you could of course sign:

{
  "type": "something",
  "state_key": "blub",
  "content": {...}
}

Is that an attack vector at all?

I don't think so.

This probably needs expanding upon, as the statement alone doesn't really explain why this is a good/bad thing or how it relates to security.

Not really sure, the avarage user will pinpoint you to your avatar anyways, no matter if the thing is cryptographically signed or not

content.unsigned is a new dict for storing things you do not wish to sign? Could you define it's purpose formally in another paragraph. I'm actually not too sure why you wouldn't want to sign part of your content?

Its purpose mostly exists to stay in-line with everything else that is signable in the matrix spec so far

Righto, so in the C-S api representation of events, the unsigned section is for the local server to drop in bits of related information that hasn't been signed by the sending server (usually because it's an age value, or prev_state, which is mutable).

In this case we don't expect any third parties to drop in bits of information into content.unsigned because servers have a section for that. Since the client is sending immutable information, I'd expect they will want to sign everything so the section feels superfluous to me.

Might be easiest to include it already in case we have usecases for it in the future. Will note in the MSC that it doesn't really have any usecase yet. Does that seem OK?

I think until someone comes up with a valid use case for it, it's probably not worth speccing it (given these MSCs take ages to go through anyway, there should be ample time for someone to shout).

I'm just thinking that because content is guaranteed to be immutable, there is little argument for including it. Sorry :(

there is little argument for including it.

Greater code simplicity as signing code clients have will already strip signatures and unsigned

There is a valid usecase: A proxy (like pantalaimon, only pan doesn't make sense as pan does e2ee, but a different kind of proxy) could add additional information into the unsigned block.

It doesn't, because you do not include the state_key in the stripped content. You'd need to define that. (argh message races :|)

Have you considered how redactions will be handled?

If the new content signature is covered by the existing hash/signature then it will not be able to be redacted when the ”content” is removed. If it isn’t covered by the existing hash/signature then it is also forgeable by the homeserver.

No, redactions have actually not be considered yet. However, why would they have to be considered specially? The homeserver can just clear out the content alltogether for redactions, like it currently does.

A server will alwasy be able to forge an event being redacted or simply not deliver an event properly. Soru is not sure what a preventable attack vector would be here.

The server cannot do this without modifying the hashes/signatures of the event and/or the event ID (room v3+later).

the server could still modify type / state key directly before persisting it into its storage, so directly before it generates the event ID.

Furthermore, this also has to be safe for v1 rooms

But those keys are covered by the hashes/signature of the event, so if you change those fields, you invalidate the origin hashes/signatures.

You can change them already right when the user posts the event to the room, before you send it over to other servers. So right when calling /send/