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

[Tony Arcieri]

On Sun, Oct 2, 2016 at 2:23 AM, Hanno Böck <hanno at hboeck.de> wrote:

> * I assume your intention is to standardize an encryption layer only
>   and not a new messaging protocol, right?


Yes


> 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.
>

Well, I think ideally there could be interoperable, IETF-standardized
protocols built on it. The Matrix.org work comes to mind. But... baby
steps. The interoperable primitives need to be put in place first.


> * 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.?
>

What form would this actually take in something like an RFC? A
non-normative section on deployment advice?


> * Is metadata hiding a design goal?
>

IMO, no. As desirable as that is and as much as I want to see it widely
deployed, it's still too much of a nascent research area, whereas I think
we're to the "rough consensus and running" code stage of something like the
Signal Protocol, and it's seen the same sort of organic proliferation of
the design we saw with djb's ciphers prior to standardization work by the
CFRG and TLS WG.

* How does this relate to other standardization efforts? (You already
>   mentioned olm, there's also OMEMO which is currently gaining some
>   traction.)
>

Ideally the output of such an WG should be an RFC that protocols like OMEMO
can reference in their own RFCs, if they ever intend to pursue IETF
standardization.


> * 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.
>

As an IETF protocol it would have to be free of IP Rights concerns. Unless
IPR can be clarified, the design would need to be changed to one which is
free of concerns.


> * 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 don't think the goal of the WG should be to rubber stamp the Signal
protocol, however I do think it's a compelling candidate if IPR concerns
can be clarified.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20161002/73cbaf1e/attachment.html>