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

[Hanno Böck]

On Sun, 2 Oct 2016 12:14:15 -0700
Tony Arcieri <bascule at gmail.com> wrote:

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

I don't know, it's more a problem description than a solution.
I just think this is one of the reasons why OTR has often caused bad
usability experiences. Several XMPP features no longer work once you
use OTR, and I think that's because these questions haven't been
answered in this case.

I think the best I can propose is to seek early involvement of the
people trying to build similar things. Naturally that would be the
OMEMO designers (I informed the main person behind omemo about this
discussion).

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

I generally agree.
But I think there are still some considerations of metadata hiding that
can go into such a protocol.
There recently was a discussion afair that on gpg messages you can see
an id of the encryption key in the encrypted message. Also one should
avoid leaking things like "this is a file transfer / this is a text
message" on the outside and wrap that all into the encryption layer.

I.e. one could strive for some kind of weak metadata protection that
doesn't work on the routing layer (source and destination still
visible), but on the application feature layer.


-- 
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/20161004/9b35945c/attachment.sig>