Re: [cti-taxii] DRAFT language for TAXII transport specification

TAXII servers MUST use HTTPS [RFC7230] and implement TLS version 1.2 [RFC5242].

Rationale:

There has to be some level of guaranteed implementation such that clients connecting to servers know they have some minimal level of security present. Servers may implement higher levels of security. Moreover, an operator can chose to implement policies to require clients use these higher levels of security, as such policies are dictated not by interoperability but by local requirements. Conversely, an operator may choose to allow clients to use lower levels of security. However, the server still needs to implement the baseline, secure level of security in the event a client needs that level of security by the client’s security policy.

TLS 1.0 and below are known broken. There are enough TLS 1.2 libraries out there that mandating TLS 1.2 is not a burden.

TLS 1.2 supports cipher suite negotiation.

For servers where the operator policy is to have unencrypted connections, the server can offer the NULL TLS cipher suite.

TAXII servers MUST implement TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 [RFC5489].

Rationale:

Any cipher suite not implementing perfect forward encryption is known breakable. Elliptic Curve RSA negotiation with 256-bit AES is sufficient for consumer-grade encryption. As SHA-1 is known breakable, we specify a SHA-2 hash. This is the minimum cipher suite for a server to implement. A server may implement higher levels of security. Moreover, an operator can chose to implement policies to require clients use these higher levels of security, as such policies are dictated not by interoperability but by local requirements. Conversely, an operator may choose to allow clients to use lower levels of security. However, the server still needs to implement the baseline, secure level of security in the event a client needs that level of security by the client’s security policy.

As an implementation note, if unencrypted channels, a server could implement TLS_ECDHE_RSA_WITH_NULL_SHA384. However, at that point, if integrity is also not important, the server could save compute cycles by negotiating to the NULL cipher suite.

With the exception of TLS_ECDHE_RSA_WITH_NULL_SHA384 and the NULL cipher suites, a TAXII server MUST NOT offer or negotiate (bid down) an encrypted connection with parameters weaker than TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.

Rationale:

This prevents bid-down attacks, except for the case of a server that offers clear text transfers. In the latter case, this prevents a server from allowing a bid-down attack that appears to offer an encrypted connection when the connection is really vulnerable.

TAXII clients MUST use HTTPS [RFC7230] and implement TLS 1.2 [RFC5242]. TAXII clients can expect conforming TAXII servers to implement at least TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 [RFC5489]. With the exception of TLS_ECDHE_RSA_WITH_NULL_SHA384 and the NULL cipher suites, a TAXII client MUST NOT offer or negotiate (bid down) an encrypted connection with parameters weaker than TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.

Some implementation notes:
Operators deploy TAXII clients and servers per their local security policy. The requirements for a TAXII server to implement HTTPS, TLS 1.2, and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 set a minimum baseline for servers such that in any environment sufficient security is available to clients that desire it. From an interoperability perspective, even if a particular deployment might not care about any security or integrity or privacy at all, and as such would be happy to have clients and servers totally vulnerable to man-in-the-middle attacks and privacy leakage, there will be many deployments that will require the minimal level of security offered by HTTPS/TLS 1.2/ECC-AES-SHA-2. As such, if a “TAXII server” does not implement this baseline, it cannot call itself a ‘TAXII’ server. Likewise, a TAXII client that fails to implement TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 may find itself unable to communicate with a TAXII server.

If local policy at the TAXII server is to allow transfers in the clear, in the TLS handshake the server can offer TLS_ECDHE_RSA_WITH_NULL_SHA384 for integrity checked transfers or the NULL cipher for insecure transfers. If local policy at the TAXII client is to allow transfers in the clear, the client can also offer in the TLS handshake TLS_ECDHE_RSA_WITH_NULL_SHA384 for integrity checked transfers or the NULL cipher for insecure transfers. Normal TLS negotiation will result in the appropriate cipher suite per the mutually agreed to security level.

We expect many deployments will have more stringent security policies. For example, this TAXII specification is silent on certificate authorities. For many uses, the Web model of having hundreds of root certificate authorities may be sufficient. For other users, a single or at most a pair of root certificate authorities may be mandated. For other users, a self-signed certificate may be sufficient. All of these policies are up to the organizations deploying the TAXII clients and servers. This specification allows for the range of totally open (hundreds of ‘recognized’ root certificate authorities) to totally closed (only a single, either hard-coded, physically distributed, or limited set of potentially pinned certificate authority, perhaps self-signed by a closed user community).

Likewise, the TAXII specification is silent as to validation and revocation policy. This is again a policy issue. We would expect most TAXII servers to implement the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP) [RFC6960]. However, that is a policy issue, not a mandate for implementation.

cti-taxii message