diff options
Diffstat (limited to 'clog.md')
| -rw-r--r-- | clog.md | 124 |
1 files changed, 0 insertions, 124 deletions
diff --git a/clog.md b/clog.md deleted file mode 100644 index 8466e27..0000000 --- a/clog.md +++ /dev/null @@ -1,124 +0,0 @@ -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. |