Section 7.4.4. "Mandatory use of the KeyHash for encrypted messages" has a very loose definition of the computation of the KeyHash which duplicates what is well specified in RTPS 2.5 section 9.6.4.8.

This duplication should be replaced with a reference to RTPS 2.5

NIST has already finalized some PQC standard.
NIST is recommending companies to start integrating PQC in 2025–2030 and will start deprecating the quantum-vulnerable ones in 2035.

See. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

As part of getting ready for a PQ world we should consider whether there is a need to create a TypeObjectV3 that uses a different hash function for uniquely identifying types.

Certificates (and permission documents) have an expiration time. A system that is runnung beyind the expiration needs to be able to get and oropaget a new certificate withity shutting down and haveing to run re-autheticatioin/key exchange, etc.

There is no specified mechanism to do this so that it can work across vendors.
A summery of the kinds of things that would need to be added is below.

Update the class id minor version in all tokens

From 1.2 to 1.3.

Fix the class ids for several of the secuerity tokens

The class_id attribute in various Tokens includes the Plugin Name and a version number. The intention was that the version number would track the specification version so that it could be used to understand the format of the Token. However, this is not done consistently. Furthermore, when there are multiple tokens with the same class id, they are differentiated by appending the '+' character and a suffix. This is not done in all cases.

We will fix the following irregularities:

Add the IdentityCredentialToken type

The class_id for the token will be DDS:Auth:PKI-DH:1.3+IdCred.

Fix the PermissionsCredentialToken property name

From dds.pem.cert to c.perm.

Changes to the Governance Document

Add the <identity_credential_authority_validation> xml complex optional type with two <ocsp> and <crl> optional elements. Their possible values are AUTO, REQUIRED, and IGNORED.

New authentication properties

• Added the dds.sec.auth.ocsp_responder_uri property for configuring the OCSP responder.
• Added the dds.sec.auth.crl property for configuring the Certificate Revocation List.

Changes to the Security Plugins Interface

Authentication plugin

• get_identity_credential_token
• return_identity_credential_token
• set_remote_identity_credential_token
• set_remote_identity_status_token
• set_property_qos
• validate_status

Access Control plugin

• set_remote_permissions_credential_token
• set_property_qos
• validate_status

Cryptography plugin

• set_property_qos

Changes to the listener classes

• on_status_changed operation for the AccessControlListener interface
• Add the AccessControlStatusKind enum with PERMISSIONS_CREDENTIAL as the only value currently possible.
• Modify the AuthStatusKind enum kind so that besides the current IDENTITY_STATUS value, it also supports IDENTITY_CREDENTIAL, IDENTITY_VALIDATION_CONTEXT, and ALL.

Document with the proposal can be found in:
https://rtiinc1-my.sharepoint.com/:w:/r/personal/reinier_rti_com/_layouts/15/doc2.aspx?sourcedoc=%7BAAA789BB-DDD8-45F3-BB07-CA9B4FAA718E%7D&file=dds_security_v12_formal1_clean-feedback.docx

Currently PSK secured messages can optionally use AAD. However if AAD is not used it would create a weakness that can be exploited to tamper with the RTPS header.

The proposed remediation is to force use of AAD if using PSK or Header Extension.

Proposed changes
In:
Table 80 – Actions undertaken by the operations of the builtin Cryptographic CryptoKeyTransform plugin
encode_rtps_message
1) Transformation when “Additional Authenticated Data (AAD)” is disabled.

Replace:
The SecureRTPSPrefixSubMsg PreSharedKeyFlag shall be set if encode_rtps_message was called with transform_with_psk=TRUE.

With

The encode_rtps_message operation will fail if it is called with transform_with_psk=TRUE and AAD is disabled.

In
Table 80 – Actions undertaken by the operations of the builtin Cryptographic CryptoKeyTransform plugin
decode_rtps_message
2) If SecureRTPSPrefixSubMsg’s PreSharedKeyFlag is set:
[..]
Uses the PSK KeyMaterial to validate the authentication tags contained in the
SecureRTPSPostfixSubMsg.

Add

The SecureRTPSPrefixSubMsg’s AdditionalAuthenticatedDataFlag must be set. The decode_rtps_message operation will fail if it is called for a message that sets the PreSharedKeyFlag flag but not the AdditionalAuthenticatedDataFlag.

DDS Security 1.2 added two elements to the Governance XSD: enable_key_revision and rtps_psk_protection_kind.
These elements were added without specifying a value for minOccurs which according the XSD rules it would default to 1. The result of this is that existing governance documents would not be valid according to the XSD. This was not the intent.

Instead the elements should have been added specifying minOccurs="0" and maxOccurs="1".

This change impacts the machine-readable file omg_shared_ca_governance.xsd

The PSK plugins does not have any description of the Logging plugin. This section should be added

Note that PSK cannot re-use the same exact approach as the "PKI"-based plugins because the logging topic there uses submessage protection and the PSK plugins do not implement this.

Currently
DDS:Security:LogTopicV2 is the topic used in the Builtin Security Plugins for logging, and it has submessage protection.
Also the Builtin Security Plugins treat the DDS:Security:LogTopicV2 topic according to the following topic rule:

<topic_rule>
    <topic_expression>DDS:Security:LogTopic*</topic_expression>
    <enable_discovery_protection>FALSE</enable_discovery_protection>
    <enable_read_access_control>TRUE</enable_read_access_control>
    <enable_write_access_control>FALSE</enable_write_access_control>
    <metadata_protection_kind>SIGN</metadata_protection_kind>
    <data_protection_kind>ENCRYPT</data_protection_kind>
</topic_rule>

Proposed change:
There should be a new “logging topic” for the Builtin PSK Security Plugins. It should be secured as:

<topic_rule>
    <topic_expression>DDS:Security:PSK:LogTopic</topic_expression>
    <enable_discovery_protection>FALSE</enable_discovery_protection>
    <enable_read_access_control>FALSE</enable_read_access_control>
    <enable_write_access_control>FALSE</enable_write_access_control>
    <metadata_protection_kind>NONE</metadata_protection_kind>
    <data_protection_kind>NONE</data_protection_kind>
</topic_rule>

The new topic should have the same type, BuiltinLoggingTypeV2.
The new topic name should be DDS:Security:PSK:LogTopic.

The security spec does not explicitly mention that the secure volatile channel must use encryption.

This probably belongs to chapter 10, as the impacted configuration is the PluginEndpointSecurityAttributes.

The specification should state that, for the BuiltinParticipantVolatileMessageSecureWriter & BuiltinParticipantVolatileMessageSecureReader, the attribute is_submessage_encrypted in the PluginEndpointSecurityAttributes (see 10.4.2.5) shall be set to TRUE .)

The same applies to the endpoints used by the TypeLookupService.

Additionally, we should discuss whether the TypeLookupService needs to be configurable to use origin authentication or this potential weakness is reasonable given the use to propagate type objects whose hashes are known.

Additional Background

The DDS Security 1.2 Specification already includes the PID_AVAILABLE_BUILTIN_ENDPOINTS_EXT Parameter ID, which advertises the availability of the Secure TypeLookup Built-In Endpoints.

PID_PARTICIPANT_SECURITY_PROTECTION_INFO is about propagating the protection kind. It has a standard part (participant_security_attributes) and a vendor-specific part (plugin_participant_security_attributes).

Proposed approach:

Add a new boolean member to ParticipantSecurityConfig in section 9.4.2.4
Add a new bit to the ParticipantSecurityAttributesMask mask in table 34:

Add two additional bits in the plugin_participant_security_attributes mask (table 67):

The presence of these flags will depend on the protection kind that the user configures for the type lookup endpoints. This configuration will be done in the Governance Document.

Add a new optional xml element, child of the domain_rule (similar to the existing monitoring_logging_protection_kind elements for configuring the monitoring endpoints). The name for the new element will be <type_lookup_protection_kind>. The possible values will be: NONE, SIGN, ENCRYPT, ENCRYPT_WITH_ORIGIN_AUTHENTICATION, SIGN_WITH_ORIGIN_AUTHENTICATION.
If the Governance Document doesn’t include the <type_lookup_protection_kind> tag but the user configures type lookup service, then the default value of ENCRYPT will be used.

Missing update reference to S/MIME version 4.0 in supporting DoD S/MIME requirements

Dear OMG Team,

we have found a security vulnerability in the DDS Security Specification [1] that we would like to disclose to your security contact directly.

Would you please send us the email address of the person in charge of handling security vulnerability for the mentioned specification?

Thank you and best regards from Germany,

FZI Security Research Team

[1] https://www.omg.org/spec/DDS-SECURITY

Use of CryptoTransformKeyRevisionIntHolder alias in operation parameters

The DDS Security Specification 1.2 defines the CryptoTransformKeyRevisionIntHolder type as:

typedef int32 CryptoTransformKeyRevisionIntHolder;

The SPIs should use this type consistently where appropriate.
For example, activate_key_revision SPI uses CryptoTransformKeyRevisionIntHolder to type its key_revision parameter. However, the key_revision parameter of create_local_datawriter_crypto_tokens, create_local_datareader_crypto_tokens and create_local_datareader_crypto_tokens is an int32.

This should be changed so all these operations use CryptoTransformKeyRevisionIntHolder

Clarify section “9.8.10.2 Key Exchange with remote DataReader

The description in page 182 should clarify that that the participant can call create_local_datawriter_crypto_tokens multiple times (to get a crypto token sequence for different revisions).

In section 10 and its subsections there are two properties that are named incorreclty in that a "." has been used instead of a "_". Specifically there are places in the section that use the names
"rtps_psk.secret_passphrase" and "rtps_psk.symmetric_cipher_algorithm"

These should be replaced with:
"rtps_psk_secret_passphrase" and
"rtps_psk_symmetric_cipher_algorithm"

Which are the names that appear in the "Configuration Properties" tables in the "Property Name" column.