2 ms·

I don't understand this: there's nothing intrinsic to e2e that makes interoperability particularly hard. There are multiple open-source e2e protocols that demon

I don't understand this: there's nothing intrinsic to e2e that makes interoperability particularly hard. There are multiple open-source e2e protocols that demonstrate this tidily, and my understanding is that there are governments in the EU that are adopting e.g. Matrix for this reason. > show a sign similar to ssl warnings in browsers to the other side that this user is using an archival api service. There is no sound way to do this and there probably never will be, especially if the protocol is interoperable and therefore the user can pick any client they please. The other client can always lie about what it's doing or circumvent detections through analogue means, e.g. pointing a camera at the screen.

Analemma_ 1y ago
If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface. Multiple critical SSL/TLS CVEs-- including some we know for a fact the NSA relied on-- came from cipher negotiation.
- woodruffw 1y ago
  > If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface. Not really. The degree of malleability in cipher negotiation is widely considered to have been a Bad Move in SSL/TLS's early design, and modern (well-designed) cryptographic protocols don't enable the kinds of parametric malleability that made SSL/TLS so exploitable at the time. Signal's protocol, for example, is perfectly interoperable; the lack of interoperability comes from a (not unreasonable) constraint at the application layer, not the protocol itself. Another example would be MLS[1], which supports fixed suites rather than parametric malleability and uses the technique from RFC 8701[2] to prevent clients from getting clever and trying to add their own extensions that undermine the fixed suites. [1]: https://datatracker.ietf.org/doc/rfc9420/ https://datatracker.ietf.org/doc/rfc9420/ [2]: https://www.rfc-editor.org/rfc/rfc8701.html https://www.rfc-editor.org/rfc/rfc8701.html

Analemma_ 1y ago

If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface. Multiple critical SSL/TLS CVEs-- including some we know for a fact the NSA relied on-- came from cipher negotiation.

woodruffw 1y ago
> If you have interoperability, then you need cipher negotiation between clients with different capabilities (and they will always have different capabilities), and that's a huge, juicy attack surface. Not really. The degree of malleability in cipher negotiation is widely considered to have been a Bad Move in SSL/TLS's early design, and modern (well-designed) cryptographic protocols don't enable the kinds of parametric malleability that made SSL/TLS so exploitable at the time. Signal's protocol, for example, is perfectly interoperable; the lack of interoperability comes from a (not unreasonable) constraint at the application layer, not the protocol itself. Another example would be MLS[1], which supports fixed suites rather than parametric malleability and uses the technique from RFC 8701[2] to prevent clients from getting clever and trying to add their own extensions that undermine the fixed suites. [1]: https://datatracker.ietf.org/doc/rfc9420/ https://datatracker.ietf.org/doc/rfc9420/ [2]: https://www.rfc-editor.org/rfc/rfc8701.html https://www.rfc-editor.org/rfc/rfc8701.html