On Sun, 2 Oct 2016 12:14:15 -0700 Tony Arcieri <basc...@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: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
pgpIB6pL26VKt.pgp
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
