Support for OTRv4

[claucece]

Hi!

Thanks so much for this amazing project! I met some of the members of it during a CCC, and it was truly awesome!

I'm currently leading the design and implementation of OTRv4. The protocol is basically finished, and over the next months we are finishing the main library and a prototype implementation on ChatSecure.

We were wondering if there is any will to implement OTRv4 over here, as we can work together in a document of how OTRv4 will work over IRC and, of course, IRCv3 (prior to any implementation).

Let us know if that will be something you are interested in!

cc/. @DrWhax @rosatolen

[slingamn]

I'm very excited about this :-)

As I understand it, existing implementations of previous OTR versions simply send the OTR message as the final PRIVMSG parameter, relying on OTR's fragmentation support (since the maximum message size for this parameter is approximately 400 bytes). I think this is probably still the right way to go.

The alternative would be sending the message as a client-only tag, which can carry approximately 4 KB of data, but this seems like it would create backwards compatibility problems and the potential benefit is only performance (since every fragment has to be transmitted with redundant IRC protocol metadata).

Prekeys present a more difficult problem. To the best of my knowledge, there is currently no standard mechanism by which an IRC server or network can hold signed prekeys on behalf of an offline user.

[GIJack]

Prekeys present a more difficult problem. To the best of my knowledge, there is currently no standard mechanism by which an IRC server or network can hold signed prekeys on behalf of an offline user.

Good time to introduce them. I made a suggestion for a C2S file transfer/proxy protocol. Perhaps that could be of use.

[DrWhax]

I don't think you'd need a file transfer proxy protocol for IRCv3. It would be easier to have something like a "KeyServe" where the IRC implementation can send prekeys to after a key has been generated.

If someone is not online, then it would retrieve a prekey from "KeyServe" this way. /msg keyserve retrieve $nick

[grawity]

I don't think you'd need a file transfer proxy protocol for IRCv3. It would be easier to have something like a "KeyServe" where the IRC implementation can send prekeys to after a key has been generated.

If someone is not online, then it would retrieve a prekey from "KeyServe" this way. /msg keyserve retrieve $nick

That might be easy to implement, but honestly? I really, really don't want any new protocol to be built around pseudo-clients with special magic nicknames. I think it's already bad enough with current IRC services that all networks have to resv nicknames like 'Q' and ten different variations of 'NickServ' so that a user couldn't pretend to be a network component and receive sensitive data (or in this case provide bad keys?); it would be even worse to have it enshrined in an actual spec.

[DrWhax]

I don't think you'd need a file transfer proxy protocol for IRCv3. It would be easier to have something like a "KeyServe" where the IRC implementation can send prekeys to after a key has been generated. If someone is not online, then it would retrieve a prekey from "KeyServe" this way. /msg keyserve retrieve $nick

That might be easy to implement, but honestly? I really, really don't want any new protocol to be built around pseudo-clients with special magic nicknames. I think it's already bad enough with current IRC services that all networks have to resv nicknames like 'Q' and ten different variations of 'NickServ' so that a user couldn't pretend to be a network component and receive sensitive data (or in this case provide bad keys?); it would be even worse to have it enshrined in an actual spec.

Do you have any suggestions on how to do it right or just a simply, let's not support end-to-end encryption?

[SadieCat]

How is this handled with other protocols?

[DrWhax]

How is this handled with other protocols?

There's a current OTRv4 pre-key implementation for Prosody, an Lua based XMPP server: https://github.com/otrv4/otrng-prekey-server

Specification can be found here: https://github.com/otrv4/otrv4-prekey-server

[SadieCat]

How does an XMPP client discover the prekey server? Who provides it?

[DrWhax]

How does an XMPP client discover the prekey server? Who provides it?

Clients use this: https://github.com/otrv4/otrv4-prekey-server/blob/master/otrv4-prekey-server.md#a-prekey-server-for-otrv4-over-xmpp

It uses 'Service Discovery' which is an XMPP XEP (a sort of sub-specification) for a client to detect the prekey server and if it's supported.

[claucece]

@SadieCat the server does not to be trusted, btw, in OTRv4. Clients only need a place to publish that could be later discoverable. We are writing now an XEP around all of this ;)

[SadieCat]

Ah, so the prekey server exists within the XMPP server?

It sounds like we could provide an OTRPREKEY ISUPPORT token for discovery then have a command for setting and retrieving keys for accounts?

[claucece]

It sounds like we could provide an OTRPREKEY ISUPPORT token for discovery then have a command for setting and retrieving keys for accounts?

I think that could work. Something that we did for XMPP, was to create a list of issues that need to be address for it to work: https://github.com/otrv4/OTRv4-over-XMPP/issues?q=is%3Aissue+is%3Aclosed

Something similar can be done for IRC and IRCv3, as well ;)

[slingamn]

A clarification: in my opinion, prekeys are not part of the minimum viable product for "OTRv4 support". (And if we ignore the prekey issue, then we're already ready to go; all other aspects of OTRv4 can be tunneled in the PRIVMSG parameter, as in previous versions.)

I like this ISUPPORT proposal. However, I think that major IRC networks (in particular, Freenode) will not have native support for prekeys anytime soon. In addition to a token value that indicates that the IRC server itself can function as a prekey server, I think it would be useful to have a token value that indicates that the client should use an external prekey server according to some protocol. (Would it be possible to simply use an XMPP prekey server for this purpose? It sounds like the spec for uploading prekeys to an XMPP server does not rely on any XMPP-specific properties, even for bootstrapping.)

[GIJack]

msg keyserve retrieve $nick

That is a good interim solution. What REALLY needs to be done is sunset traditional services, and do everything in band server with consistent accounting, perhaps with database back-ends, with the nick,oper,chan,memo-server being legacy mechanisms.

I think that major IRC networks (in particular, Freenode) will not have native support for prekeys anytime soon

This is why it needs to be part of an RFC and it needs to be a prereq for advertising IRCv3 support.

[SadieCat]

A clarification: in my opinion, prekeys are not part of the minimum viable product for "OTRv4 support".

I don't think we should ship half a specification. Either support the entire protocol or nothing at all.

[DrWhax]

A clarification: in my opinion, prekeys are not part of the minimum viable product for "OTRv4 support". (And if we ignore the prekey issue, then we're already ready to go; all other aspects of OTRv4 can be tunneled in the PRIVMSG parameter, as in previous versions.)

I like this ISUPPORT proposal. However, I think that major IRC networks (in particular, Freenode) will not have native support for prekeys anytime soon. In addition to a token value that indicates that the IRC server itself can function as a prekey server, I think it would be useful to have a token value that indicates that the client should use an external prekey server according to some protocol. (Would it be possible to simply use an XMPP prekey server for this purpose? It sounds like the spec for uploading prekeys to an XMPP server does not rely on any XMPP-specific properties, even for bootstrapping.)

Mixing protocols gets very messy very quickly, I personally wouldn't want to go down that path. An external prekey server (meaning, outside of the IRC network) doesn't sound like a good idea either.

So ideally, i'd like to have it within the IRC network which would also run the prekey server.

[slingamn]

That's fair. I think the important thing to remember here is that major IRC networks will almost certainly not have prekey support for a long time, probably on the order of years.

The spec should be written in a way that makes it clear that client support for OTRv4 is not contingent on server support --- online session initiation will work even without support for prekeys.

[claucece]

@slingamn The specification is written in that way. It even clarifies that you can have different modes on how you implement it: https://github.com/otrv4/otrv4/blob/master/otrv4.md#otrv4-modes. And there is a separate specification around the server: https://github.com/otrv4/otrv4-prekey-server/blob/master/otrv4-prekey-server.md

In practice, you can use any place as a publishing place, as that place is untrusted, as long as the native protocol has a way to discover that place. But inside of a specific protocol, it is better to use the capabilities of that same protocol.

[claucece]

Support for only having online conversations is possible with OTRv4, and it corresponds to mode: 'OTRv4-interactive-only' (you will still need here a publishing place -can be the same prekey server- for Client Profiles and Prekey Profiles). The mode is described here: https://github.com/otrv4/otrv4/blob/master/modes/otrv4-interactive-only-mode.md

However, supporting only online will mean no offline conversations, which in practice reduces usability: as people more and more rely on being able to start offline conversations with contacts.

[claucece]

A cool thing that we can do is a repo for all of these thoughts, as a starting point (I'll create one in a minute).

It will be cool to also have some input from @dgoulet and @ahf as they worked doing an OTR plugin for IRC (in irssi) in the past. ;)

[claucece]

So, here is the repo: https://github.com/otrv4/OTRv4-over-IRC

[ahf]

Sorry for the late response. Work is keeping me a little bit busy right now.

I think OTRv4 would be great to have in an IRC context. I feel I'm missing context though on how this related to the IRCv3 work that is also ongoing? Is there a summary of the conversation from CCC somewhere?

[dequis]

Is there a summary of the conversation from CCC somewhere?

That was just me and @SadieCat walking up to the stage after their 35c3 talk to say hi. It's been like 50 years since then so I don't really remember.

I think it wasn't much more than "check ircv3 out, we got out of band message tags and per-user metadata which miiiight make sense for otr". Just to throw the idea out there, to say that we exist and might have solutions to prekey problems.

[claucece]

@ahf @dequis Yeah, it went that way on CCC ;) But now, we have more time to actually look at OTR over IRCv3 and IRC ;)

@ahf more than anything, I'll also like to know if while doing OTR over IRC you encountered some problem or something that needed more thought besides what was specified on the protocol...