95 lines
3.3 KiB
Plaintext
95 lines
3.3 KiB
Plaintext
CAP prefix/clog
|
|
===============
|
|
|
|
Copyright (c) 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
|
|
|
|
prefix/clog=hash_type,hash_type/tag,tag,tag
|
|
|
|
Example:
|
|
|
|
prefix/clog=sha1,sha256/server-time
|
|
|
|
`server-time` is always implicitly specified, and should be omitted.
|
|
|
|
The `HASH` S2C command
|
|
----------------------
|
|
|
|
The `HASH` command shall be sent 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` message tag
|
|
----------------------
|
|
|
|
The `hash` mesaage tag shall be sent with every `PRIVMSG`, `TOPIC` and `NOTICE`.
|
|
|
|
Syntax:
|
|
|
|
hash=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.
|
|
|
|
Example:
|
|
|
|
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.
|
|
|
|
[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.
|