x/gov & x/group proposal IDs could be spoofed by UIs

[aaronc]

Problem

Currently proposal IDs are just auto-assigned integers. A UI could show the wrong proposal content and a user could vote on it without knowing they are voting for the wrong thing. This could be mitigated by lite client proofs in the UI, but currently these aren't well-supported. This could especially be an issue when x/group is used as a multisig.

Possible Solutions

The most obvious solution is to make the proposal ID the hash of the proposal content (msgs + metadata) plus some nonce so that the user will see the proposal hash in the UI as well as Ledger signing interface. The user would still need to very that the hash matches the content, but this is somewhat easier than making a full lite client proof.

Going one step further, it would be great if the sign mode textual could actually show the proposal content in the Ledger UI. This could work if there was some way to annotate certain Msg fields as "links" and then display the linked content.

One potential issue with hashing is that we don't yet have guaranteed canonical protobuf serialization... although this is planned for pulsar.

/cc @cmwaters @blushi @AmauryM

[amaury1093]

Is the threat model here a malicious UI, but signing still done on a trusted device like Ledger/Keplr?

1. if we do hash, the malicious UI can show the correct proposal hash, but malicious contents that don't match the hash. The user will never check the hash themselves match (or to paraphrase Juan: it's useless to put hashes on signing screens).
2. if we do light client, the same attack can happen as the user will never check the proof.

Alternative solution: proposal_id as slug

Maybe we can do a human-readable ID? Make proposal_id a string that would represent the proposal slug. It should be limited in length (e.g. 20 or 40 chars), chosen by the proposer, and should succintly describe the proposal.

Then in MsgVote, the voter signs this slug.

Possible attacks:

• 1st case: malicious proposer but honest UI: when the voter reads the proposal, they might notice that the slug (e.g. software_upgrade_v045) chosen by the proposer doesn't match the metadata/Msgs (e.g. MsgSend), so won't vote. ✅
• 2nd case: honest proposer but malicious UI (described in the OP): the proposer makes an honest software_upgrade_v045 proposal, but the UI shows a completely different proposal. Assuming the signing device is trusted (e.g. Ledger/Keplr), then the voter would see that what they are signing (software_upgrade_v045) doesn't match what the UI showed, and something's fishy. ✅
• 3rd case: malicious proposer and UI: the proposer creates software_upgrade_v045 when it's actually a MsgSend, and the UI also shows it's a software upgrade. The user is spoofed. ❌

(note: to keep state small, we can still keep the proposal_id index as uint, and add a new required proposal_slug field).

[aaronc]

Thanks for that analysis @AmauryM 👍 .

So I think having slugs is not a bad idea in general. I wonder if @hxrts has any thoughts?

It seems, however, that the only thing that would really solve this for the Ledger is something like "links" where the signing UI actually shows the proposal content.

I would say that a hash probably isn't totally useless if there is some trust model with the UI, which may be the case on mobile devices or with trusted https domain.

[hxrts]

I kind of like being able to know the proposal sequence due to explicit enumeration and as you say slugs don't really solve the problem. I think the hashing method is simple and straightforward. A long textual output is going to be hard to confirm on the ledger anyway, with a hash you could do so pretty quickly. Definitely something we should fix but pulling off a governance attack with this would be pretty challenging so I feel comfortable waiting until deterministic proto serialisation is complete.

[tac0turtle]

@facundomedica does sign mode textual now display any information about the proposal?