[Advanced Security/Security Baseline] TLS versions

[MariaYa0091]

It is currently unclear which TLS versions device suppose to support (except some newer add-ons). And Security Baseline has TLS1.2 and TLS1.3 listed in informative section and only TLS1.2 looks like required if provided chippers list will be combined with normative section.

At the same time the following descriptions exists with TLS 1.0 and TLS 1.1 requirements (see pictures at the end).

So what is TLS requirements (not recommendations) for ONVIF Device in general?

RFC 2246 is TLS 1.0
RFC 4346 is TLS 1.1

ONVIF Security Configuration Specification (only couple of examples listed, there is more)

ONVIF Streaming Specification (Normative references section links only to TLS 1.0)

[bsriramprasad]

As per my understanding, unless there is something explicitly prevented or written down, existing tls-configuration-add-on allows older versions?

All the new profiles that are WIP and refer to security baseline will require tls1.2 and above.

[MariaYa0091]

As per my understanding, unless there is something explicitly prevented or written down, existing tls-configuration-add-on allows older versions?

All the new profiles that are WIP and refer to security baseline will require tls1.2 and above.

Yes, it allows everything below. The problem, that Network Specification requires supports of TLS 1.0 and TLS 1.1. New profiles do not cancel these requirements, but add new on top of this.

So formally during the testing of Profile V DTT shall require support of TLS 1.0, TLS 1.1 for communication to Device AND TLS 1.2 for communication from Device.

[jflevesque-genetec]

There's already a capability TLSServerSupported which indicates which version of TLS the device supports. I believe the different sections need to be rewritten in a way that don't require a specific version of TLS to work, since the concept is pretty broad and not specific to a version of TLS. If it has to be tied to an RFC specifically, in that case I would expand on what the 1st screenshot exposes, something like:

TLS is a protocol defined to establish an encrypted connection over TCP initially defined in RFC2246. Subsequent versions of TLS are defined in their own RFC. Any mention of TLS within this specification is agnostic of which TLS version is being used unless specified.

[MariaYa0091]

Please be aware that TLSServerSupported is optional for devices. And if used it obligates devices to support TLS server configuration (for device to be server). For example pure Profile V device will not return this capability.

[HansBusch]

@MariaYa0091 the Core specification should no more require a specific TLS version.

Once Profile S is discontinued we can deprecate GetCapabilities and we should look at some outdated security capabilities. Unfortunately the SecurityCapabilities element is mandatory. Hence suggest to only leave xs:AnyAttribute inside for backward compatibility.

[MariaYa0091]

@HansBusch I do not talk about GetServiceCapabilities of Device Service or GetCapabilities, also it is not Core Specification.

About my last comment, you could apply it to Profile T. Profile T has HTTPS as conditional feature, but do not require Advanced Security.

Also I do not think you could remove all SecurityCapabilities, user management is still a part of Core.

[HansBusch]

Just double checked the Profile-T specification. The only wording that I could find is mentioning of HTTPS. Profile T relates to Specification 18.06. Even that version already deprecates TLS version capabilities:

[kieran242]

@MariaYa0091 @HansBusch @jflevesque-genetec @bsriramprasad @sujithhanwha
I see that Maria is requesting a clear definition of the handling of TLS versions. for support of DTT & CTT features I further agreed with JF comment clarity is required in some way in the Security Spec and Baseline. Hans and @bsriramprasad also are indicating that TLS 1.0 & 1.1 should be supported as per TLS 1.2 & 1.3 for Profile V and TLS configuration going forward. This I also understand the logic and reasons for the same.

This needs discussed directly in Prague with VE and with Maria in attendance to define clearly how this can be resolved.

[sujithhanwha]

Closing this since PR is open for this issue.