-
Key: DDSSEC11-40
-
Status: closed
-
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
-
Summary:
Currently securing the RTPS message requires duplicating the RTPS header between the SecurePrefix and the SecureSuffix in order to be able to encrypt and sign.
This may be useful when encryption is needed as it wold allow to put a "fake" RTPS header and obscure the content of the real one.
However when we are signing only having the INFO_SOURCE seems an unnecessary duplication as it would be sufficient to include the existing RTPS in the computed MAC.
To implement this it would be enough to add a flag to the SecurePrefix that indicates that the SecureSuffix MAC is done all the way from the beginning of the RTPS message (i.e. including the RTPS header).
However this would break interoperability with any applications that do not understand this new flag...
The only approach I can think of that does not break interoperability would be to add the flag to the SecureSuffix and include both signatures. One that does not include the RTPS header (for legacy applications) and one that does. The problem is that this would add the extra computation (and size) of the second signature which seems more expensive than just adding the INFO_SOURCE...
-
Reported: DDS-SECURITY 1.0 — Mon, 21 Nov 2016 16:29 GMT
-
Disposition: Closed; No Change — DDS-SECURITY 1.1
-
Disposition Summary:
Not worth doing as it would break backwards interoperability
The RTF task force decided it was not worth breaking backwards interoperability in order to gain what seems like fairly minimal performance.
-
Updated: Tue, 19 Dec 2017 20:03 GMT
DDSSEC11 — Remove duplicate of RTPS message inside the security envelope
- Key: DDSSEC11-40
- OMG Task Force: DDS Security 1.1 RTF