Allow host chain to limit ICA functionality

[seantking]

Summary

At present, an interchain account can execute any sdk message sent by the Controller chain, so long as the Host chain supports this functionality. During requirement gathering, several high-profile chains made it clear that they will not use interchain accounts unless there is built-in functionality for a host chain to specify a list of SDK messages that an interchain account cannot execute.

This is briefly mentioned in the specification but has not been outlined clearly with regards to the implementation details. I think this is open to discussion. My initial thoughts are that we can simply pass in a list of message types in app.go to the ICA keeper initialization as an optional parameter. Any SDK messages in this list will be not be executed by the host chain.

This is probably a nice to have but I think it is a security feature that a lot of people will want from day one.

@AdityaSripal @colin-axner @damiannolan @crodriguezvega thoughts?

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[AdityaSripal]

Your proposal makes sense to me. Is the only request to bar messages based on message type? We don't need any more granular restrictions correct?

[seantking]

Great point. The requests so far have just been based on the message type. I think anything more granular than that can be left for future versions (if it gets requested).

[AdityaSripal]

Cool, makes sense to me. Your solution seems simple enough. This should just be passed in on the host side

[colin-axner]

Can we just make this an on-chain parameter? Otherwise we require coordinated upgrades to modify this list. The parameter can be a list of strings which are the proto URLs of the message types

[seantking]

Agree with @colin-axner.

Reference for whoever picks this up: https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/params.go

[andrey-kuprianov]

From the security perspective, I would make this feature to use a whitelist instead of a blacklist, i.e. to allow the host chain to specify a list of messages that it allows to execute.

Otherwise, in the blacklist approach (when a host chain specifies a list of SDK messages that an interchain account cannot execute), some new messages are bound to be added in the future, that the host chain will find undesirable, but which will slip through the blacklist sieve. This, on the one hand, can be a source of security vulnerabilities, on the other -- will probably require much more frequent updates to the list of unwanted messages.

[seantking]

@andrey-kuprianov thanks for your input. @AdityaSripal voiced a similar concern lately. I agree with your approach 🤝 We will make this a whitelist rather than a blacklist.

[damiannolan]

closed by #576