TODO-SILC

   1 SILC Protocol
   2 =============
   3
   4 Possible SILC protocol and specification document changes.  All of these
   5 are tentative and doesn't mean that any of them would be done at any
   6 point.
   7
   8  o Full rework of the documents as requested by RFC Editor.  The plan
   9    is to create only two documents:
  10
  11    silc-architecture-xx.txt
  12    silc-specification-xx.txt
  13
  14  o Make @ reserved character in channel names.  Accept channel@server
  15    names in all commands and notify types.
  16
  17  o Add acknowlegments section to specification documents.
  18
  19  o Group Diffie-Hellman protocol for establishig key with two or more
  20    users on a channel.
  21
  22  o Change CTR mode description:
  23
  24     Truncated HASH from SKE (4 bytes) - This value is the first 4
  25     bytes from the HASH value that was computed as a result of SKE
  26     protocol.  This acts as session identifier and each rekey MUST
  27     produce a new HASH value.
  28
  29    to
  30
  31     Truncated HASH from SKE (4 bytes) - This value is the first 4
  32     bytes from the HASH value that was computed in SKE.  In each rekey
  33     the value MUST be recomputed as follows:
  34
  35       HASH = hash(new Sending/Receiving IV from SKE)
  36
  37     The hash function is the one used in SKE.  The 'new Sending/Receiving
  38     IV from SKE' is the first 8 bytes of the new value computed during
  39     rekey.  The first 4 bytes are used from the recomputed HASH.
  40
  41  o Consider for future authenticated encryption modes, especially GCM.
  42
  43  o Extend the Channel ID port to be actually a counter, allowing the
  44    2^32 channels per cell, instead of 2^16 like now.  The port with
  45    compliant implementation would always be 706, and it could be used
  46    as a counter, starting from 706... For interop, with old code.
  47
  48  o In SKE with UDP/IP responder doesn't have to do retransmissions.
  49    Initiator will retransmit its packet.  Initiator can be considered
  50    the one that actually WANTs to establish the keys.  So no need for
  51    responder to retransmit.  Define this clearly in the specs.
  52
  53  o Define clearly that the DSS signature format is the the Dss-Sig-Value
  54    ASN.1 encoding defined for PKIX.
  55
  56  o Define clearly the SSH2 signature format is the one specified for SSH2
  57    protocol.
  58
  59  o Dynamic server and router connections, ala Jabber.  SILC has allowed
  60    this from the beginning.  It should be written out clearly in the
  61    specs.  Connection would be created with nick strings (which are of
  62    format nick@server).
  63
  64  o NAT detection protocool during SKE so that party behind NAT can
  65    detect if it is behind NAT and receive the public IP address and port
  66    that it may need (servers need it to create valid Server ID).  (***DONE)
  67
  68  o Counter block send/receive IV 64 bits instead of 32 bits, and the
  69    value itself is used as 64-bit MSB ordered counter, which must
  70    be reset before the packet sequence counter wraps.  It's basically
  71    a counter which is initially set to a random value. (***DONE)
  72
  73  o Nickname to NEW_CLIENT packet. (***DONE)
  74
  75  o Add Source and Destination ID in message MAC computation to fully
  76    associate the Message Payload with the true sender and the true
  77    recipient of the message.  This will fix some security issues that
  78    currently exists.  It is currently possible in some specific set of
  79    conditions to mount a replay attack using Message Payload.  This change
  80    will remove the possibility of these attacks.
  81
  82    After including Source and Destination ID in message MAC, ONLY replay
  83    attack possible is the following and with ONLY following conditions:
  84
  85    1. the attacker is able to record encrypted Message Payloads and has
  86       the ability to replay them.
  87    2. the message payload is encrypted with static private message key
  88    3. the original sender of the message is not anymore in the network,
  89       has changed nickname, has detached and resumed, or has reconnected
  90       to other server.
  91    4. the original receiver of the message is still in the network, has
  92       not changed nickname, has not detached and resumed, and has not
  93       reconnected to any other server, or, some other user has the same
  94       client ID.
  95    5. the attacker is able to get the same client ID as the original
  96       sender.
  97    6. the original receiver still has the static key set for the same
  98       remote client ID (for original sender's client ID).
  99
 100    All this is possible to happen though likelyhood is quite small.  It
 101    does illustrate how inappropriate the use of static keys is. (***DONE)
 102
 103  o The SILC public key identifier separator is ', ' not ','.  The
 104    whitespace is mandatory. (***DONE)
 105
 106  o Definition of EAP as new authentication method for connection auth
 107    protocol (RFC 3748).
 108
 109  o Count limit to LIST command?
 110
 111  o Strict announces if Channel ID is different than on router?  To not
 112    allow any modes, topic, etc changes from server if the ID was wrong
 113    initially?  Meaning: riding with netsplits not possible since the
 114    channel created during split will not enforce is modes to the
 115    router.  Or more liberal solution, like now?  Read emails on
 116    silc-users.  (This is very old issue)
 117
 118  o The time values in STATS is 32-bits.  After 2038 it's over 32-bits.