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

[Tom Ritter]

On 2 October 2016 at 04:23, Hanno Böck <hanno at hboeck.de> wrote:
> Hi,
>
> 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
>   confirmations etc.?
> * 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
>   traction.)
> * 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 pretty much with Hanno on most of these.  I'd be willing to help
with the IETF work to make this happen, but I'm worried about his
points and at what level things would be done.

If it's crypto only, something more for the CFRG, I'm wondering if
Trevor would prefer to do something himself. If it's wire format, I
think we're _probably_ going at too low a depth although I could be
convinced otherwise.

If it's somewhere in between, I'm wondering about how decisions will
be made regarding different use cases:
- Would we acquiesce to an x509 style extension system?
- Do we skip extensions but decide explicit version non-compatibility
with a version negotiation?
- Do we design it with the specific intention of a central prekey
distribution server, with that component being optional, or try to do
both?

I guess I'm also a little confused about the license of Signal
Protocol/Axolotl. The version that's currently implemented in the code
is not the version that's marked as placed in the public domain
(AFAIK). This makes things a little ambiguous; although easily cleared
up.

-tom