How to handle the Prekey server about otrv4-over-irc

[jwheare]

For clarity, can you describe the scope and query/storage properties of the publishing place that are required?

Would ircv3 METADATA work? e.g. you can GET against a target (nick or channel) for a specific key name and get back a value that has been SET. Anyone can query that data, usually only a user (or the server/opers) can set it against their own nick.

[dequis]

See ircv3/ircv3-specifications#279 for the metadata deprecation

It's only "deprecated" in that version because we don't want to recommend implementing that version without the changes in ircv3/ircv3-specifications#339

It doesn't mean the concept is dead.

[DrWhax]

Oh but that's interesting to know! In that case, would it work out if we draft something up for OTRv4 and the metadata proposal?

[jwheare]

I think it's still the case that a rewritten metadata proposal would not suit the storage and processing needs of a prekey server.

[DrWhax]

I think it's still the case that a rewritten metadata proposal would not suit the storage and processing needs of a prekey server.

I'll come back to this after reading the pull request.

[slingamn]

I think the distinction referred to here is this: with NickServ, authenticating to an account looks like PRIVMSG NickServ :identify account_name password. Because the command is just being passed as a chat message to a "user" with a special-cased nickname, the input and the responses are basically freeform text. At best, they are de facto standardized, at worst they're totally unpredictable.

In contrast, authentication with SASL uses native protocol messages that are easier to specify, standardize, and automate, as in these examples:

1. https://ircv3.net/specs/extensions/sasl-3.1#example-protocol-exchange
2. https://ircv3.net/specs/extensions/sasl-3.2#examples

[slingamn]

Continuing discussion from ircv3/ircv3-ideas#67:

1. You said in a comment that the mode 'OTRv4-interactive-only' still requires third-party infrastructure to publish Client Profiles and Prekey Profiles. However, the spec states that 'OTRv4-interactive-only' is usable over services like Ricochet that lack any such infrastructure. If I'm understanding correctly, 'OTRv4-interactive-only' works without this infrastructure, but with the loss of some deniability properties?
2. Is there a specification for a generic prekey server, perhaps over REST?

My main concern here is that for the foreseeable future (on the order of five to ten years, probably), the overwhelming majority of IRC users will not be using a server with native support for prekeys. So there's a compelling reason to look for alternative solutions. But if the use of a generic prekey server is too crufty, maybe the best alternative is just the OTRv3-compatible mode.

Just to clarify, I'm not opposed to specifying native IRC commands for handling prekeys --- I just want to emphasize the tradeoffs involved in getting OTRv4 into the hands of real users.

[claucece]

Hey!

Thanks for the questions.

You said in a comment that the mode 'OTRv4-interactive-only' still requires third-party infrastructure to publish Client Profiles and Prekey Profiles. However, the spec states that 'OTRv4-interactive-only' is usable over services like Ricochet that lack any such infrastructure. If I'm understanding correctly, 'OTRv4-interactive-only' works without this infrastructure, but with the loss of some deniability properties?

I think you are confusing a 'place to publish' (whatever that is, it can even be a tweet, that a client can define and ask things for) and central infraestructure. OTRv4 does not require central infrastructure. It requires a place where things can be published and later retrieved.

If I'm understanding correctly, 'OTRv4-interactive-only' works without this infrastructure, but with the loss of some deniability properties?

No. The phrase you are quoting is "keep in mind, though, that if OTRv4 is used over Ricochet, some online deniability properties will be lost." If you use OTRv4 over an anonymity network, you can loose online deniability, as the two cryptographic properties might cancel themselves out.

Is there a specification for a generic prekey server, perhaps over REST?

REST is software architectural style. OTRv4 deals with specifications as a cryptographic protocol or with recommendations over how to handle it over a messaging/underlying protocol. If what you are talking about is how to handle OTRv4 over html, then there is no specification.

My main concern here is that for the foreseeable future (on the order of five to ten years, probably), the overwhelming majority of IRC users will not be using a server with native support for prekeys. So there's a compelling reason to look for alternative solutions. But if the use of a generic prekey server is too crufty, maybe the best alternative is just the OTRv3-compatible mode.

All of the modes need a place to publish, because all the modes require a Client Profile.

Thanks!

[slingamn]

There are two areas I can think of where previous METADATA proposals are lacking something:

1. Prekey messages actually get used up when they are distributed/consumed. ("As a consequence, the OTRv4 protocol can be subject to DoS attacks by an attacker draining the Prekey Ensembles for another user. This can be partially mitigated using fetch rate limiting.") There is currently no provision for handling this with METADATA.
2. Did the previous metadata proposal address what happens when the client goes offline? AFAICT it's unspecified. I'm guessing the typical ircd implementation will default to making metadata available only while the client has an active connection.

If what you are talking about is how to handle OTRv4 over html, then there is no specification.

HTTP, not HTML, but --- why not? The main problem that occurs to me is that it's desirable for administrative control over the chat network to translate directly to administrative control over the prekey server (e.g., to ensure that Client Profiles correspond to chat network accounts in a straightforward way), and this is harder if the prekey server is not fully integrated with the protocol.

[claucece]

For clarity, can you describe the scope and query/storage properties of the publishing place that are required?

Sure! Basically, the prekey server (named here 'server', but does not have to necessarily be a traditional server) needs to:

1. Be able to receive certain data from clients and store it (the data is: Client Profile, Prekey Profile and Prekey messages: a Prekey Ensemble). This data is stored in association with an identifier (username, for example) and a device identifier. The server should return a message saying that the submission was successful or not.
2. Be able to perform a DAKE with the client. A DAKE is a serious of steps done in order to deniably authenticate each other (from a party publishing the Prekey Ensembles and the server), so a deniable channel can be created for the submission of the Prekey Ensemble
3. Be able to receive requests from an 'x' party asking for the Prekey Ensembles of another party. For example, Bob wants to start an offline conversation with Alice (who is offline). Bob, therefore, asks the Prekey server for the Prekey Ensemble for Alice. The Prekey Server checks there are Prekey Ensembles in their storage and submits them to Bob. If there are none, the Prekey Server returns an error.
4. Be able to tell the publisher when the number of Prekey Ensembles in storage is getting low, so the publisher (Bob, in the aforementioned example) can publish more.

The data that is stored is just a series of characters that don't need to remain secret. Therefore, the Prekey Server is untrusted. That is why publishing to another place like a tweet can work as well, as long as the publishing process is done in a deniable way by executing a DAKE, and, as long as the retriever knows this is where it was published and can get the data from there.

Would ircv3 METADATA work? e.g. you can GET against a target (nick or channel) for a specific key name and get back a value that has been SET. Anyone can query that data, usually only a user (or the server/opers) can set it against their own nick.

I'll have to carefully read this specification. But thanks for letting me know of this! I'll try to read this this weekend, and then let you know if it can work ;)

Thanks!

[claucece]

Prekey messages actually get used up when they are distributed/consumed. ("As a consequence, the OTRv4 protocol can be subject to DoS attacks by an attacker draining the Prekey Ensembles for another user. This can be partially mitigated using fetch rate limiting.") There is currently no provision for handling this with METADATA.

OTRv4 does not require any provision for this. The protocol is aware that Prekey Ensembles can run out.

Did the previous metadata proposal address what happens when the client goes offline? AFAICT it's unspecified. I'm guessing the typical ircd implementation will default to making metadata available only while the client has an active connection.

I don't understand this. Can you clarify? The usage of Prekey Ensembles is precisely for offline conversations, just like Signal, OMEMO or Wire.

HTTP, not HTML, but --- why not? The main problem that occurs to me is that it's desirable for administrative control over the chat network to translate directly to administrative control over the prekey server (e.g., to ensure that Client Profiles correspond to chat network accounts in a straightforward way), and this is harder if the prekey server is not fully integrated with the protocol.

Right now, we have seen no need for creating a specification of OTRv4 over HTTP, and it seems like there could be other options of IRC. If there will be an specification for HTTP, it will be in another repository and not over the IRC ideas ;)

Thanks!

[DrWhax]

There are two areas I can think of where previous METADATA proposals are lacking something:

1. Prekey messages actually get used up when they are distributed/consumed. ("As a consequence, the OTRv4 protocol can be subject to DoS attacks by an attacker draining the Prekey Ensembles for another user. This can be partially mitigated using fetch rate limiting.") There is currently no provision for handling this with METADATA.

I guess just to add to what @claucece mentioned, DoS isn't part of the threat model, not sure if rate limiting will do much, at some point the prekeys run out and then you'll just get a notification that prekeys are out and you have to wait for this person to come online again and upload prekeys.

Are you referring to the IRCv3 metadata proposal? That seem to be deprecated? https://ircv3.net/specs/core/metadata-3.2

[slingamn]

To clarify the limitations of METADATA, or rather, the previous metadata proposal:

1. The prekey server spec says "5. The Prekey Server removes the selected Prekey Messages from its storage" --- i.e., retrieving a prekey causes it to be deleted. This doesn't fit well into the METADATA model (which, simplifying a bit, is a key-value store where a user sets keys on their own profile and other users can retrieve them but not modify them).
2. In general, the METADATA key-value model doesn't seem like a good fit for something that actually has to perform computations (e.g., composing the Prekey Ensemble Retrieval Message from the client profile and the prekey message).

re. persistence: traditionally, the core of the IRC network (made up of "IRC servers", or "ircds") has no persistent state: all state is tied to active client connections. All data that persists after the client connection is lost is held by a special-purpose node called the "services framework" and manipulated using special-purpose commands (e.g., sending messages to NickServ and ChanServ) that are not part of the core protocol. (I think this is more or less what was being suggested on the other issue with "KeyServe".)

Typical IRCv3 extensions do not change this assumption: they must be implementable without requiring the retention of data after the client is offline. On my reading of the previous METADATA specification, it is not an exception to this rule. In particular:

For the purposes of this specification, ‘targets’ are entities for which metadata may be set. Such entities MUST be a valid nickname or channel.

Since it says "nickname" and not "account name" or "services username", (in contrast to, e.g., the account-tag specification), the implication is that this data may be ephemeral (as nicknames are) and un-retrievable when the client is offline.

[slingamn]

Are you referring to the IRCv3 metadata proposal? That seem to be deprecated? https://ircv3.net/specs/core/metadata-3.2

Correct --- even if this extension were fit for purpose (and as far as I can tell, it is not), it is deprecated.

[slingamn]

I'm commenting in the continued belief that metadata won't work for this (in fact, that nothing in the current core IRCv3 protocol will work for this, because of the design assumption that the core is stateless).

The main options here seem to be:

1. Design an extension to the core protocol that is not stateless
2. Design this as a new "service", outside the core protocol in the way other stateful extensions like NickServ and ChanServ are (call this "KeyServ")
3. Design a generic version of this that works over REST or something similar

The advantages of (3) seem pretty compelling to me --- not because REST is good, but because it's a de facto standard, because it has the potential to save a lot of specification and implementation effort, and because a key advantage of earlier versions of OTR was that they could be tunneled over any messaging protocol that could carry printable ASCII characters, even if the platform was indifferent or hostile to E2EE. For example, what's the plan for doing OTRv4 over Slack or Discord? It seems unlikely that the relevant corporations will build "native" infrastructure to support this.

[DrWhax]

I'm commenting in the continued belief that metadata won't work for this (in fact, that nothing in the current core IRCv3 protocol will work for this, because of the design assumption that the core is stateless).

The main options here seem to be:

1. Design an extension to the core protocol that is not stateless

2. Design this as a new "service", outside the core protocol in the way other stateful extensions like NickServ and ChanServ are (call this "KeyServ")

I think this is the easiest for now.

3. Design a generic version of this that works over REST or something similar

Maybe and thanks for pointing us towards this. But I don't think ircd's would ever deploy "KeyServ" if we'd do it in a REST way.

The advantages of (3) seem pretty compelling to me --- not because REST is good, but because it's a de facto standard, because it has the potential to save a lot of specification and implementation effort, and because a key advantage of earlier versions of OTR was that they could be tunneled over any messaging protocol that could carry printable ASCII characters, even if the platform was indifferent or hostile to E2EE. For example, what's the plan for doing OTRv4 over Slack or Discord? It seems unlikely that the relevant corporations will build "native" infrastructure to support this.

There aren't any plans right now for this.

[jwheare]

The non-standard nature of *Serv services and the way they communicate via normal chat messages is a pretty big implementation blocker on the whole. I'm far more interested in developing things like SASL and standard account registration protocols rather than doubling down on ad hoc services for any future IRC ecosystem functionality.

[slingamn]

Maybe and thanks for pointing us towards this. But I don't think ircd's would ever deploy "KeyServ" if we'd do it in a REST way.

The suggestion is more that someone --- not necessarily the IRC network operator --- could deploy a single REST-based key service that could be used across multiple organizations and protocols (e.g., three different IRC networks, Slack, and Discord).

As I understand it, you've already thought about how to do this kind of "bridging", e.g., with the suggestion that the client profile could be published in a tweet. I'd like to understand more about how that works...

[DrWhax]

The non-standard nature of *Serv services and the way they communicate via normal chat messages is a pretty big implementation blocker on the whole. I'm far more interested in developing things like SASL and standard account registration protocols rather than doubling down on ad hoc services for any future IRC ecosystem functionality.

I'm not fully up-to-date on the SASL workings. So excuse me if I should have done my homework better in the past. But wouldn't that mean that you can only use the KeyServ if you're authenticated through SASL?