DDSSEC11 — Handling large numbers of receiver-specific MACs

The builtin crypto plugins sign messages with one MAC (common_mac) computed with a key shared with all the DataReaders followed by a sequence of MACs (receiver_specific_macs) each signed with a different key shared with only one DataReader.

This approach ensures that a DataReader cannot impersonate the DataWriter and sign messages that other readers would validate as originating from the DataWriter.

This approach results on two issues that need to be addressed:

• Handling message sizes that approach/exceed the transport MTU
• Handling large numbers of DataReaders

The first problem appears because at the time the data sample is written by a DataWriter the DDS implementation needs to know how to fragment it. To do this is uses the known maximum transport MTU as well as knowledge of the overhead due to RTPS headers, etc. This overhead can take into consideration the extra DDS-Security sub-messages. However if the size if the signature depends on the number of matched DataReaders it is not possible to know it at the time the sample is written..

The second problem appears when we have very large number of matched DataReaders. At some point the overhead of 32 bytes per remote reader starts being excessive in terms of both extra message size as well as the performance to compute each separate MAC.

The specification should provide some means to handle these issues. A potential approach is this:

• Allow the DataWriter to be configured with a maximum number of remoter_reader_macs. As long as the number of DateReaders does not exceed it the DataWriter will sign the message with each receiver-specific MAC. Given this maximum the system knows the maximum RTPS overhead and therefore when to fragment large messages.

• If the number of matched DataReaders exceeds the specified maximum then the DataWriter has two possibilities:

1. It could reuse the same MACs, that is, share the same receiver-specific Key with multiple DataReaders. This would allow certain reader to impersonate the DataWriter but it will only affect the other readers sharing the same receiver-specific key.

2. Use a fast digital signature algorithm. This would keep the size of the message fixed and may have additional benefits for messages that are relayed by a persistence service or a routing service

Looking at the literature of fast digital-signature algorithms one that seems popular is Ed25519. See https://ed25519.cr.yp.to/

Allow an Endpoint to configure a maximum number of "receiver-specific" MACS

Specify that a DataWriter can be configured with a maximum number of receiver_specific_macs. As long as the number of matched DateReaders does not exceed it the DataWriter will sign the message with each receiver-specific MAC. Given this maximum the system knows the maximum RTPS overhead and therefore when to fragment large messages.

If the number of matched DataReaders exceeds the specified maximum then the DataWriter can share the same receiver-specific MACs for more than one reader. This weakens origin authentication. Alternatively the DataWriter could use a different strategy (e.g. send the message multiple times, each limited to the maximum number of receiver_specific_macs) as long as it does not impact interoperability wit receivers that are not aware of this strategy.