Add an extension TLV to upgrade to v4
SoniEx2 opened this issue · comments
This extension TLV should do all the key exchanges and whatnot necessary to maintain the current SMP/fingerprint validation state. This extension TLV would be ignored by OTRv3 libraries - only OTRv4 libraries would recognize it.
(Technically if you already did SMP/etc, you have a secure channel, so you should just be able to send your fingerprints over it... still seems like a bad idea tho. .-.)
This extension cannot be added here, as OTRv4 cannot modify the past.
A library supporting OTRv4 is compatible to OTRv3 if the participant send a query message or whitespace tag only supporting OTRv3. Then the connection will be OTRv3.
If the need is:
- Having a connection with OTRv4 and downgrade to OTRv3: you will need to define in your policies that you only want to talk OTRv3 and restart the conversation so a new query message is sent. This is insecure as the security properties are downgraded.
This will be an extension to OTRv3 which is what this project is not.
What's wrong with extending the old protocol to support a path to upgrading to the new protocol and deprecating the old one?
Should there be a whitespace tag that is sent inside OTRv3 connections to indicate OTRv4 upgrade path? (Should you do a whole OTRv4 connection inside OTRv3?)
The whole point is to ditch OTRv3, not to keep using it.
Is OTRv3 insecure enough that you need to completely ditch peer verification (either manual fingerprint validation, or SMP validation) before being able to benefit from OTRv4's increased privacy guarantees? Like... OTRv3 is still a secure channel. In fact OTRv4 even says OTRv3 may still be used, so it's not like the crypto is broken.
The only thing preventing two OTRv4 clients from using OTRv4 instead of staying on OTRv3 indefinitely, is having to re-do the fingerprint/SMP validation. If the privacy benefits are actually worth it, then there should be a way to upgrade protocol versions while maintaining said validation.
What's wrong with extending the old protocol to support a path to upgrading to the new protocol and deprecating the old one?
We don't control the libraries and how they were implemented in the past. If developers want to support OTRv4, they have to include it in the way they seem fit in their libraries. We can only specify from onwards. OTRv4 is compatible with OTRv3, but not the other way around as it often happens with any other protocol.
Is OTRv3 insecure enough that you need to completely ditch peer verification (either manual fingerprint validation, or SMP validation) before being able to benefit from OTRv4's increased privacy guarantees?
I don't understand this. OTRv4 supports peer verification as well.
The only thing preventing two OTRv4 clients from using OTRv4 instead of staying on OTRv3 indefinitely, is having to re-do the fingerprint/SMP validation. If the privacy benefits are actually worth it, then there should be a way to upgrade protocol versions while maintaining said validation.
What validations are missing in OTRv4? It still has SMP and fingerprint verification.
Oh, you're not understanding us...
Okay, let's say two parties are currently on awesome-otr-plugin-1.0, which supports OTRv3 because OTRv4 isn't ready yet.
They start an OTR with eachother, they verify eachother with fingerprints or SMP, they talk some, they go sleep, they talk some more in the morning, they go sleep again, they talk some more in the next morning, and then at some point they've been doing this for a few years, on OTRv3, and awesome-otr-plugin-1.1 comes out, with OTRv4 support.
They both install the new plugin, and... unfortunately, they find themselves still on OTRv3. They think "wait, didn't we upgrade to OTRv4? what's going on?" because they don't know they're supposed to throw away the old, but still perfectly usable, OTRv3 verification and start a new one from scratch, with no help from either protocol or from the plugin.
With COVID, in-person fingerprint verification is kinda impossible nowadays, so if that was your method of choice, your only option is to keep using your existing OTRv3 session. With SMP it's a bit easier as you can just share a password over the existing OTRv3 secure channel before disconnecting it, altho that sounds kinda error-prone tbh.
But honestly, we feel like switching from OTRv3 to OTRv4 while carrying over the previous verification state should be handled by the OTRv4 library, rather than manually by the user, even if it may need to be explicitly requested by both users (with an /otr upgrade command on IRC, for example). Letting the user handle it is error-prone and could lead to a compromise.
Again, OTRv4 supports both fingerprint verification and SMP verification.
This depends on how implementers want to make their libraries. What you are asking is completely different from: a TLV, a OTRv3 extension, a OTRv4 extension. What you are asking is an implementation detail.
You will still need to re-verify the session for OTRv4 as the algorithm for them has changed (and the parameters have as well). A library can make this opaque for you by re-hashing the verification and showing it again or other mechanism. But that is a decision for the libraries, not the protocol. In regular cases, the plugin, library or whatever it is will prompt you to re-verify, and you can use SMP for this.
But what if it could re-verify without user intervention? Take advantage of the trust on the OTRv3 secure channel to negotiate trust on the OTRv4 channel.
A TLV to be sent in OTRv3 mode, dedicated for these "pre-trusted" OTRv4 session negotiations, would allow plugins an upgrade path compatible between implementations. The implementation detail would be whether to use /otr upgrade or send the TLV on the first message, not the actual upgrade protocol.
Take advantage of the trust on the OTRv3 secure channel to negotiate trust on the OTRv4 channel.
Sure, you can send the new OTRv4 SMP info over the OTRv3 channel.
A TLV to be sent in OTRv3 mode
A OTRv3 compatible mode means that OTRv4 is compatible with OTRv3, not that it modifies it. As already said, we are not modifying the OTRv3 protocol or implementations of it, which has been already said in this thread.
We don't modify OTRv3 specification or libraries. You can use OTRv4 for verification and either check the fingerprints, use a secure channel to share the SMP secret (which could be Signal, OTRv3, and many more), use an SMP secret that you know already the other party knows.
So, what exactly do you lose from specifying a cross-implementation upgrade protocol? If you're against it, there must be a reason. (Not buying this "this would require modifying OTRv3 spec/libs" when in fact it wouldn't. This is about OTRv4 libs operating in OTRv3-compatibility mode.)
Again, we are not modifying OTRv3 protocol or libraries. The idea of OTRv4 is to replace OTRv3 with a small window of compatibility with OTRv3. The idea of OTRv4 has never being to modify OTRv3.
You are confusing things over here:
This is about OTRv4 libs operating in OTRv3-compatibility mode.
This means that both an OTRv4 library and a OTRv3 library are installed in an app. It could be that both are provided in the same library but that depends on the library owner and implementation.
Locking this as this it has been already said that OTRv4 does not modify OTRv3.