diff options
-rw-r--r-- | clog.md (renamed from v0) | 226 | ||||
-rw-r--r-- | v-1 | 94 | ||||
-rw-r--r-- | v-2 | 77 |
3 files changed, 124 insertions, 273 deletions
@@ -1,102 +1,124 @@ -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.
+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. @@ -1,94 +0,0 @@ -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.
@@ -1,77 +0,0 @@ -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.
|