# Issues/PRs # Issues/PRs - PR #397 - **Good to merge.** - PR #393 - Richard: Is intent that application messages MUST NOT be plaintext? - Raphael: Yes. - Richard: I was considering a use-case where we don't use MLS framing, we just use MLS to export a key. MLS-SRTP is an example. - Raphael: If you don't want confidentiality, you can explicitly put your data in the AAD. Right now it's fragile because messages might not be encrypted and you might not notice. - **Good to merge.** - PR #396 - Brendan: This makes it seem that it's ok to not rotate your signing key if you can't secure it, when it's not ok. - Konrad: Brendan's right that rolling the signing key solves other problems. But we leave a lot of authentication out of the protocol, so I can see the value of having the membership token. - Richard: I like this because it adds enforcement of the sender.type field. - Britta: The security properties we focus on currently are also all framed in terms of the current group. - Konrad: I would feel better if we had an explicit MAC'ing primitive. - Britta: There's an authentication secret in another PR, that's specifically for this problem. - Richard: Would be my preference to derive something new off the key schedule. - **Changes requested:** use real MAC, and with new new key. - PR #389 - Richard: This PR contrasts with #369 about extensions in Commits. Need cleaner story about extending commits. I'm ok with proposals being the only extensibility method for Commits. - Rahael: Sounds viable. Right now you can omit the `path` of a Commit if it's only Adds. But if we introduce a PSK proposal, are we allowed to omit path? Not clear. - Brendan: I think extensions can arbitrarily change the processing logic for whatever is appropriate for them. - Sean: Can we merge this or do we need more changes? - Raphael: I think we need to be clearer on the logic that requires a `path` or not. - **Changes requested:** Change pseudocode to look for Updates or Removes, instead of only Adds.