An implementation that supports the Modified BCP 195 RFC 8996, 9325 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 9325] 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.

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.

Servers shall support all of the following cipher suites for TLS 1.2. Clients shall support at least one of the cipher suites defined below.

The following list of cipher suites may be used, but support is not mandatory for both servers and clients.

When using TLS 1.2, cipher suites other than those listed in the required or optional lists 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.

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.