Protocol: Feature Negotiation

[s-rah]

I'm currently building out some tools where I would like to use the feature negotiation part of the ricochet control channel.

Currently this aspect is mostly undefined in the protocol, with clients expected to return an empty string.

I'd like to clarify two points on how this negotiation should behave going forwards

1. Feature Strings should align with Channel Types e.g. im.ricochet.chat is a feature, in the context of EnableFeature.
2. To prevent fingerprinting and limit attack surface a client should only return features in FeatureEnabled that the requester is authorized i.e. before authentication a client might only return [im.ricochet.auth.hidden-service] but after authentication the client might return [im.ricochet.chat, im.ricochet.file-transfer]

Any concerns with this?

Thanks,
Sarah

[nyarly]

Please forgive my ignorance of ricochet in general. Is there any chance of downgrade attacks as a result of negotiation?

[s-rah]

Hi @nyarly - downgrade attacks tend to require a MITM posture to fully exploit, which is currently not possible with ricochet connections, with the onions providing end-to-end encryption.

It is certainly possible in the future with protocol extensions and new channel types that feature negotiation could be used to ensure a peer only communicates with you over a "weaker"/known vulnerable channel. Channels & Client will still have to ensure that they are resistant to misuse and deanonymization attacks.

If we were to find a particular channel/feature was vulnerable, then I would think the guidance would be to patch clients to ensure to remove those features.

[nyarly]

Fair enough. There is a current school of thought in the crypto community that e.g. TLS should never have included negotiation, and that the answer to protocol agility is "complete replacement."

But, I certainly don't know Ricochet well enough to understand its threat model. "Downgrade?" is a kind of Pavlovian response to "negotiation."