RFC #2: Message Sequence Field

[brannondorsey]

Proposal

Add an optional message sequence field to the chattervox packet. Initially proposed here.

Details

This functionality can be useful in determining if messages have been lost in transmission. It can also be used to protect against replay attacks in the event that clock synchronization is not possible or no timestamp field is included in the packet (see RFC #1).

This RFC proposes protocol-level support for message sequence numbers, however, it is up to the chattervox client software to choose how use them.

Considerations

• The sequence field should be optional. Applications can opt out of sequence field inclusion in their chattervox packets to reduce packet size overhead.
• Client software that supports the sequence field could alert users to message sequence gaps and aid in identifying lossy transmissions.
• The sequence field is compatible with he timestamp field RFC #1. Either, both, or neither could be used.
• Used to mitigate replay attacks, message sequence numbers are not as effective as timestamps as users are vulnerable to replay attacks that include message sequence numbers created since they last made contact with the real station. E.g. Alice and Bob are communicating in a round-table discussion in the CQ "chat room". The last message Alice hears from Bob before logging off contains sequence number 43. Once Alice has logged off, Bob continues to chat in the group and sends 100 messages, which Eve records. The next day, Alice joins the CQ while Bob is not present. She is vulnerable to replay attacks by Eve for 100 different messages that Eve heard but Alice did not. Because Bob is no longer in the room, he can not inform her that his next sequence number is 144.
• Global sequence numbers don't play nice when a station uses two different computers, each with their own message sequence counters. Support for SSIDs (e.g. KC3LZO-1, KC3LZO-2, ...) mitigates this problem to some degree. This wouldn't be a problem if the client chooses to reset the sequence number each session, but then session numbers are no longer useful to prevent replay attacks.
• The sequence number format should be large enough that messages won't rollover too frequently (or at all if used for replay attack protection) but small enough that they don't cause too much packet overhead.

Protocol Changes

Byte Offset	# of Bits	Name	Value	Description
0x0000	16	Magic Header	0x7a39	A constant two-byte value used to identify chattervox packets.
0x0002	8	Version Byte	Number	A protocol version number between 1-255.
0x0003	5	Unused Flag Bits	Null	Reserved for future use.
0x0003	1	Sequence Number Flag	Bit	A value of 1 indicates that the message contains a message sequence number.
0x0003	1	Digital Signature Flag	Bit	A value of 1 indicates that the message contains a ECDSA digital signature.
0x0003	1	Compression Flag	Bit	A value of 1 indicates that the message payload is compressed.
[0x0004]	[8]	[Signature Length]	Number	The length in bytes of the digital signature. This field is only included if the Digital Signature Flag is set.
[0x0004 or 0x0005]	[0-2048]	[Digital Signature]	Bytes	The ECDSA digital signature created using a SHA256 hash of the message contents and the sender's private key.
[0x0004-0x104]	8 or 24	[Sequence Number]*	Unsigned Integer	A message sequence number. This number should increase by one each time a new message is sent by a chattervox client.
0x0004-0x11C	0-∞	Message*	Bytes	The packet's UTF-8 message payload. If the Compression Flag is set the contents of this buffer is a raw DEFLATE buffer containing the UTF-8 message.

bold values indicate proposed changes.
[] indicates an optional field.
* indicates a member of the signed message if a digital signature is present.

Open Questions

• Should this method really be used for replay attack prevention? I don't think it is a very effective method of prevention.
• If we don't intend to use sequence numbers to defend against replay attacks, we can make the bit-length of the field much smaller. If sequence numbers are used only to indicate message gaps, an 8-bit field would probably suffice. In this case the field would be used simply to count the relative distance between received messages and not the absolute message number. Sequence number rollovers would be fine as it is unlikely that a station would miss > 255 messages before hearing a new message.
• Does adding a sequence number overstep the keep-it-simple-stupid ethos of the protocol? Does the usefulness of this feature outweigh the complexity it introduces?
• Is this something that client software should roll itself on top of the protocol instead?