4.6 KiB
CAP soniex2.github.io/clog
Copyright (c) 2018 Soni L. <fakedme plus irkv3 at gmail dot com>
This capability provides a mechanism for identifying and conveying a cryptographically secured list of messages to IRC clients.
This specification also suggests a mechanism by which IRC clients can sync logs, using the information provided by this capability.
Cap syntax
The capability shall be specified as
soniex2.github.io/clog=hash_type,hash_type/tag,tag,tag
Example:
soniex2.github.io/clog=sha1,sha256/time,soniex2.github.io/clog
time and soniex2.github.io/clog are always implicitly specified, and should be omitted.
The HASH S2C command
The HASH server-to-client command shall be sent from server to client for hashes associated with a channel.
Each hash must be a cryptographic hash. Non-cryptographic hashes must be ignored. Broken hash algorithms should be avoided. MD5 is explicitly disallowed and must not be used.
The counter must be able to store numbers in the 0..2^62-1 range.
These hashes specify the current "heads" of the clog. This is similar to git heads, if you're familiar with them.
Syntax:
HASH #channel :hash_type=counter/hash,type=counter/hash,...
Example:
>>> JOIN #channel
<<< JOIN #channel
<<< NAMES etc
<<< HASH #channel :sha1=20/something_long
<<< HASH #channel :sha1=60/something_else,sha256=70/another
Optionally, the server may include a server name with the HASH command:
<<< :server1.example.com HASH #channel :etc
<<< :server2.example.com HASH #channel :other
The HASH C2S command
The HASH client-to-server command shall be sent from client to server to view and manipulate a channel's hash list.
To view a channel's hash list:
HASH #channel
To manipulate a channel's hash list:
HASH #channel :+hash_type=counter/hash,type=counter/hash,...
HASH #channel :-hash_type=counter/hash,type=counter/hash,...
(To add and remove hashes, respectively)
Viewing a channel's hash list should be restricted to anyone capable of joining the channel. This means banned users shouldn't have access to this command.
Manipulating a channel's hash list should be restricted to channel operators only.
The clog message tag
The clog message tag shall be sent with every PRIVMSG, TOPIC and NOTICE.
Syntax:
soniex2.github.io/clog=type=counter/short_hash,type=counter/short_hash,...
The use of short_hash lowers bandwidth requirements. Consult your cryptography expert for best practices on using cryptography.
These hashes specify the previous "head(s)" of the clog. "Merges" are just messages with hashes from different sources.
The hash encompasses the message tags specified by the capability (e.g. time and clog), sorted according to UTF-8 byte order, and the contents of the IRC message, as seen in the following format:
@soniex2.github.io/clog=type=counter/full_hash,type=counter/full_hash,...;time=... :nick!user@host PRIVMSG #channel :message
(This line is what gets hashed)
Note the use of full_hash instead of short_hash.
Examples:
TODO
Security Considerations
Clogs are meant for channels that want public logging. An example is the Rust IRC channel. As such, anything in a clog should be assumed public.
It's possible to recover deleted clogs by setting up a separate IRC network and sending the right hashes on the right channel. However, you'd still need to know the hashes. Thus, this isn't a vulnerability, because if you had the hashes, you could just request the logs directly, without going through the process of setting up an IRC network.
The network could be made to sign all hashes, but you'd need to share the signing key across all servers for it to work correctly. This still doesn't prevent someone from getting access to an intercepted, correctly-signed hash, and by sharing the signing key you increase the attack surface.
The server can and should be able to "undo" hashes. This is useful if, for example, someone posts child pornography - you likely don't want that permanently recorded in a channel's history.
[FIXME there may be more]
The SYNC CTCP (informative)
This section is informative.
The SYNC CTCP is a hypothetical CTCP for syncing logs.
Syntax:
SYNC <tox-compatible public key> <port> <host> <host> <...> -[nospam+checksum]
This is a highly flexible command supporting ipv4, ipv6, hostname, tor, i2p and tox ID.
Messages sent over non-tox channels must be encrypted with the tox-compatible public key.