[messaging] IETF standardization of a next-gen messaging protocol

[Ximin Luo]

Tobias Markmann:
> On Sun, Oct 2, 2016 at 1:48 PM, Ximin Luo <infinity0 at pwned.gg> wrote:
> 
>> For sure, but then it should be called a common encryption component and
>> *not* "standardisation of a next-gen messaging protocol" (the subject of
>> this thread).
> 
> True. Maybe I've misinterpreted Tony's message. IMO standardization of the
> crypto protocol and its wire representation would have greater chances to
> wide adoption. [..]

I can see the benefits in agreeing to standardise a cryptographic component
including the packet flows and algorithms, but standardising the exact wire
representation is less useful (and people have less incentive to do it) if
there is no need for interoperation. For example, even ed25519 private keys
have no standard format; there are about 3 different ones and everyone picks
their own. Not that this *particular example* is a big deal, I'm just
demonstrating how lack of interoperability reduces the need to standardise.

In terms of adoption of a standard *messaging protocol*, well one doesn't
succeed by not trying. I know everyone has the XKCD standardisation comic in
mind, but funnily enough both the examples in that now have standards. :) And
Matrix and OMEMO are already examples of efforts in this area. (I happen to
disagree with parts of their approaches, but that's another topic.)

> [..] It wouldn't just be another messaging protocol for end-users
> but rather a core e2e encryption component that could be used in current
> and future protocols to come. Similar to TLS that is used by many other
> protocols.
> 

Not to disagree, but just a nitpick so future people don't extend this in the
wrong way: I think an analogy to WebRTC would be more accurate here.

TLS servers and clients communicate directly and the application "goes through"
TLS; nothing touches unencrypted TCP directly. However with the Signal ratchet
and with WebRTC, there are other components operating on the side that the
application chooses, that bypasses Signal and WebRTC respectively. (Sometimes
there is quite a lot here, like file transfer metadata stanzas in OMEMO.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git