DICOM PS3.15 2023a - Security and System Management Profiles

B.13 Modified BCP 195 RFC 8996 TLS Secure Transport Connection Profile

An implementation that supports the Modified BCP 195 RFC 8996 TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security protocol. It shall comply with [BCP 195] which includes [RFC 8996], and [RFC 7525] as modified by [RFC 8996] with the additional restrictions enumerated below. In the context of this profile, “client” refers to the entity initiating the TLS connection and “server” refers to the entity that is responding to that TLS connection initiation request. This may differ from the role that the entity might play in any DICOM transactions over the TLS connection.

Note

  1. A device may support multiple TLS profiles. DICOM does not specify how such devices are configured in the field or how different TLS profile-related rules are specified. The site will determine what configuration is appropriate.

  2. The DICOM profiles for TLS describe the capabilities of a product. Product configuration may permit selection of a particular profile and/or additional negotiation rules. The specific cipher suite used is negotiated by the TLS implementation based on these rules.

A client shall attempt to negotiate TLS even if the above indications are not communicated by the server.

The following cryptographic algorithms, grouped by function, shall not be used:

Only the following cryptographic algorithms, grouped by function, are permitted:

When DHE is used for Key Exchange, the key length shall be 2048 bits or more. Cipher suites containing DHE shall not be selected when using implementations that do not allow explicit setting of the DHE key length.

When ECDHE is used for Key Exchange, the key length shall be 256 bits or more.

Servers shall support all of the following cipher suites for TLS 1.3. Clients that support TLS 1.3 shall support at least one of the following cipher suites.

Note

In TLS 1.3 Key Exchange and Signature, algorithms are not specified in the cipher suite negotiation. Implementations may choose from the list above of permitted algorithms.

Servers shall support all of the following cipher suites for TLS 1.2.

The above cipher suites are preferred for TLS 1.2. Clients that support TLS 1.2 shall support at least one of the cipher suites listed above or below. Servers may support the following cipher suites as a fallback for TLS 1.2 but are not required to do so.

When using TLS 1.2, cipher suites other than those listed in either list above are not permitted.

The following requirements apply to Certificates within TLS:

Servers shall support both TLS 1.2 and TLS 1.3. Clients shall support at least one of TLS 1.2 or TLS 1.3. Clients shall attempt to negotiate TLS 1.3 if it is supported. Servers shall prefer TLS 1.3 if offered by the client. Implementations may fall back to TLS 1.2 if the client does not negotiate TLS 1.3.

In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers shall prefer strict TLS configuration.

Application protocols typically provide a way for the server to offer TLS during an initial protocol exchange, and sometimes also provide a way for the server to advertise support for TLS (e.g., through a flag indicating that TLS is required); unfortunately, these indications are sent before the communication channel is encrypted.

Servers shall support bi-directional mutual authentication. Clients are not required, but are encouraged, to support and use bi-directional mutual authentication. The server may be configured to not use bi-directional mutual authentication.

The TCP ports on which an implementation accepts TLS connections for DICOMweb shall be different from those on which an implementation accepts TLS connections for DIMSE. The HTTP/HTTPS connection for DICOMweb can be shared with other HTTP/HTTPS traffic.

Note

It is recommended that systems supporting this Profile use the registered port number "2762 dicom-tls" for the DICOM Upper Layer Protocol on TLS.

The Conformance Statement shall indicate:

When an integrity check fails, the connection shall be dropped per the TLS protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The Conformance Statement shall document the provider reasons issued by the implementation.

DICOM PS3.15 2023a - Security and System Management Profiles