If you're designing a protocol, please bear in mind that in the context of encryption "opportunistic" usually means "downgradeable to clear text".
@clacke but but but ENCRYPTION! OPPORTUNISTIC! BIG WORDS! SMOKE, MIRRORS! MAAAAGIC! ;)
@clacke but if you're designing a new protocol, why would you go with opportunistic? Just bit the bullet, make it mandatory and #TOFU!
Opportunistic is "better than nothing" *only* if adding encryption in an established protocol with an active user base/deployments that cannot be easily upgraded all at the same time.
And even then it's a fscking security nightmare, potentially giving people false sense of security.
Governments have TLS MITM capabilities already, and are using them.
@clacke Absolutely. However, I'd say that there are very few situations where there is no chance that this is not nor will ever become relevant.
Feels like it makes sense to design with this threat in mind anyway. Who knows what your protocol will be used for in 5 years, and who will want to meddle.
Regarding "Governments have TLS MITM capabilities already, and are using them", everybody should go ahead and read this: https://citizenlab.ca/2014/08/cat-video-and-the-death-of-clear-text/
Turkmenistan has MITM+malware capability. *TURKMENISTAN*.
...and that was 3 years ago.
@clacke we've also seen an Server Name Indication based website censorship (basically, censorship equipment looking at SNI in TLS ClientHello) used to block HTTPS site in Kazachstan.
Looking for ways to circumvent shit like this, but without browsers implementing domain fronting, there really is no way, it seems.
@clacke and that was ~3 years ago.