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

[Hanno Böck]

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 definitely interested in having that discussion, however I'm
unlikely to attend any of the next IETF confs outside europe in person.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20161002/91dce8e3/attachment.sig>