[messaging] IETF standardization of a next-gen messaging protocol
hanno at hboeck.de
Sun Oct 2 02:23:27 PDT 2016
I think this would obviously make sense, however I think there are
immediately a number of questions of where this endeavour should go.
* I assume your intention is to standardize an encryption layer only
and not a new messaging protocol, right? (That's the way the thing
that's commonly called the signal protocol is used right now due to
various ecosystem constrains and also the explicit wish of its main
developer.) With the implicit assumption that this protocol is
supposed to be used within separate protocols that don't
interoperate. I wonder if a design with lack of interoperability in
mindmatches IETFs goals.
* If you intend to design a crypto only layer I think this needs very
careful considerations how this is connected to the rest of a
potential protocol using it. How does it interact with application
features, e.g. voice com, file transfer, message markup, reading
* Is metadata hiding a design goal? (Or at least avoiding unneccessary
metadata leakage.) That seems to be a topic relevant for some debates
lately, however this probably needs to start by a clear definition
what metadata hiding even means.
* How does this relate to other standardization efforts? (You already
mentioned olm, there's also OMEMO which is currently gaining some
* I haven't followed closely the whole wire/signal/gplv3-debate.
However there seem to be at least some claims that every
implementation of the current signal protocol is seen as some kind of
gplv3 derivative and thus also covered by gplv3. I personally don't
have a problem with gpl code, but I don't think it's good for a
standard to have such a constraint (as you'd want it to be used)
widely. I doubt anyone wants a protocol with a cloud of legal
uncertainty over it.
* This is a bit of a fuzzy point and relates to the first one, but I'd
fear that this could turn into some kind of "let's do it like signal,
because signal is already there". I think one needs to consider that
there may be conflicts of interest between the way signal is developed
right now (e.g. goal of integration within commercial walled garden
non interoperable systems) and the goals of standardization.
I don't want to discourage your effort, quite the contrary, but I think
these are questions that need to be answered, and maybe they need to be
answered even before starting with anything else like a WG formation.
I'm definitely interested in having that discussion, however I'm
unlikely to attend any of the next IETF confs outside europe in person.
mail/jabber: hanno at hboeck.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Messaging