Malicious relayer attack preventing correct tying of connection ends

[ancazamfir]

Summary

Summarizing here discussion with @milosevic and Ilina about this and also @ebuchman on cosmos/cosmos-sdk#7870:

A connection or channel will never reach Open state if there is a mismatch in the identifiers. It is very simple to write a relayer that watches the OpenInit events from A and immediately send a MsgOpenInit to B with mismatched connection ids, blocking forever the handshake on the connection/ channel.

It may be that the “correct” relayer that would guarantee that the handshake finishes would have to do something like:

• always send MsgOpenInit without specifying the counterparty connection id (this is allowed now in order to support flexible id selection)
• specify the counterpary connection id in OpenTry (i.e. tie the two connection ends with a message that carries proofs)

So maybe one solution is to not allow the MsgOpenInit with counterparty connection_id specified.

This should be looked at more closely and determine the best solution.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[mconcat]

Without adding spec level constraints on identifiers, this would be the simplest solution.

[colin-axner]

Has this been fixed with the auto-generated identifier changes?

cc @cwgoes

[cwgoes]

Yes, this is no longer applicable, I believe.