+++ /dev/null
-SILC Protocol
-=============
-
-Possible SILC protocol and specification document changes. All of these
-are tentative and doesn't mean that any of them would be done at any
-point.
-
- o Full rework of the documents as requested by RFC Editor. The plan
- is to create only two documents:
-
- silc-architecture-xx.txt
- silc-specification-xx.txt
-
- o Make @ reserved character in channel names. Accept channel@server
- names in all commands and notify types.
-
- o Add acknowlegments section to specification documents.
-
- o Group Diffie-Hellman protocol for establishig key with two or more
- users on a channel.
-
- o Change CTR mode description:
-
- Truncated HASH from SKE (4 bytes) - This value is the first 4
- bytes from the HASH value that was computed as a result of SKE
- protocol. This acts as session identifier and each rekey MUST
- produce a new HASH value.
-
- to
-
- Truncated HASH from SKE (4 bytes) - This value is the first 4
- bytes from the HASH value that was computed in SKE. In each rekey
- the value MUST be recomputed as follows:
-
- HASH = hash(new Sending/Receiving IV from SKE)
-
- The hash function is the one used in SKE. The 'new Sending/Receiving
- IV from SKE' is the first 8 bytes of the new value computed during
- rekey. The first 4 bytes are used from the recomputed HASH.
-
- o Extend the Channel ID port to be actually a counter, allowing the
- 2^32 channels per cell, instead of 2^16 like now. The port with
- compliant implementation would always be 706, and it could be used
- as a counter, starting from 706... For interop, with old code.
-
- o In SKE with UDP/IP responder doesn't have to do retransmissions.
- Initiator will retransmit its packet. Initiator can be considered
- the one that actually WANTs to establish the keys. So no need for
- responder to retransmit. Define this clearly in the specs.
-
- o Define clearly that the DSS signature format is the the Dss-Sig-Value
- ASN.1 encoding defined for PKIX.
-
- o Define clearly the SSH2 signature format is the one specified for SSH2
- protocol.
-
- o Dynamic server and router connections, ala Jabber. SILC has allowed
- this from the beginning. It should be written out clearly in the
- specs. Connection would be created with nick strings (which are of
- format nick@server).
-
- o NAT detection protocool during SKE so that party behind NAT can
- detect if it is behind NAT and receive the public IP address and port
- that it may need (servers need it to create valid Server ID). (***DONE)
-
- o Counter block send/receive IV 64 bits instead of 32 bits, and the
- value itself is used as 64-bit MSB ordered counter, which must
- be reset before the packet sequence counter wraps. It's basically
- a counter which is initially set to a random value. (***DONE)
-
- o Nickname to NEW_CLIENT packet. (***DONE)
-
- o Add Source and Destination ID in message MAC computation to fully
- associate the Message Payload with the true sender and the true
- recipient of the message. This will fix some security issues that
- currently exists. It is currently possible in some specific set of
- conditions to mount a replay attack using Message Payload. This change
- will remove the possibility of these attacks.
-
- After including Source and Destination ID in message MAC, ONLY replay
- attack possible is the following and with ONLY following conditions:
-
- 1. the attacker is able to record encrypted Message Payloads and has
- the ability to replay them.
- 2. the message payload is encrypted with static private message key
- 3. the original sender of the message is not anymore in the network,
- has changed nickname, has detached and resumed, or has reconnected
- to other server.
- 4. the original receiver of the message is still in the network, has
- not changed nickname, has not detached and resumed, and has not
- reconnected to any other server, or, some other user has the same
- client ID.
- 5. the attacker is able to get the same client ID as the original
- sender.
- 6. the original receiver still has the static key set for the same
- remote client ID (for original sender's client ID).
-
- All this is possible to happen though likelyhood is quite small. It
- does illustrate how inappropriate the use of static keys is. (***DONE)
-
- o The SILC public key identifier separator is ', ' not ','. The
- whitespace is mandatory. (***DONE)
-
- o Definition of EAP as new authentication method for connection auth
- protocol (RFC 3748).
-
- o Count limit to LIST command?
-
- o Strict announces if Channel ID is different than on router? To not
- allow any modes, topic, etc changes from server if the ID was wrong
- initially? Meaning: riding with netsplits not possible since the
- channel created during split will not enforce is modes to the
- router. Or more liberal solution, like now? Read emails on
- silc-users. (This is very old issue)
-
- o The time values in STATS is 32-bits. After 2038 it's over 32-bits.
-
- o Consider for future authenticated encryption modes.
projects / crypto.git / blobdiff