Initial commit. Add all known versions of newclog.

Version 0 is the latest.

Version -1 is the second latest.

Version -2 is the third latest.

Versions -3 and back, I didn't manage to recover.
This commit is contained in:
SoniEx2 2018-09-14 02:42:25 -03:00
commit 791ab635f6
3 changed files with 273 additions and 0 deletions

94
v-1 Normal file
View File

@ -0,0 +1,94 @@
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.

77
v-2 Normal file
View File

@ -0,0 +1,77 @@
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.
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.
Example:
TODO
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.

102
v0 Normal file
View File

@ -0,0 +1,102 @@
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,prefix/hash
`server-time` and `prefix/hash` are 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:
prefix/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.
The hash encompasses the message tags specified by the capability (e.g. `server-time` and `hash`), sorted according to UTF-8 byte order, and the contents of the IRC message, as seen in the following format:
@prefix/hash=...;server-time=... :nick!user@host PRIVMSG #channel :message
(This line is what gets hashed)
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.