Summary

The uri-options specification permits drivers to enable TLS implicitly when tls-prefixed options are present, but does not define when that happens. From the tls row of the options table:

TLS required if "mongodb+srv" scheme; otherwise, drivers may enable TLS by default if other "tls"-prefixed options are present
Drivers MUST clearly document the conditions under which TLS is enabled implicitly

The rationale explains the intent:

It can be useful to turn on TLS implicitly when options such as "tlsCAFile" are present and "tls" is not present. However, with options such as "tlsAllowInvalidHostnames", some drivers may not have the ability to distinguish between "false" being provided and the option not being specified. To keep the implicit enabling of TLS consistent between such options, we defer the decision to enable TLS based on the presence of "tls"-prefixed options (besides "tls" itself) to drivers.

The rationale suggests a distinction: tlsCAFile is cited as a good case, and tlsAllowInvalidHostnames as a problematic one, but the specification never states it normatively, and nothing in the test suite constrains the outcome. Whether a given connection string produces an encrypted connection is therefore driver-defined and unverified.

What is under-specified

1. Which options. "Other tls-prefixed options" is not enumerated. These fall into at least two natural groups:

• options that supply TLS material: tlsCAFile, tlsCertificateKeyFile, tlsCertificateFile, tlsPrivateKeyFile
• options that only modify TLS behavior: tlsInsecure, tlsAllowInvalidCertificates, tlsAllowInvalidHostnames, tlsDisableOCSPEndpointCheck, tlsDisableCertificateRevocationCheck, tlsCertificateKeyFilePassword

Supplying a CA file without intending TLS is hard to imagine; relaxing a TLS check on a connection that was never going to be encrypted is easy to imagine. The spec does not say whether the two groups should behave alike.

2. Whether the value matters. For boolean tls-prefixed options, is TLS enabled by the option's presence, or only by a true value? The rationale acknowledges that some drivers cannot distinguish false from absent, but for drivers that can, it gives no guidance. Without one, tlsAllowInvalidHostnames=false may enable TLS in one driver and not another.

3. Override and ordering. The spec does not state that an explicit tls=false takes precedence over implicit enablement, nor does it address position within the query string. A driver applying options in encounter order can produce different results for ?tls=false&tlsCAFile=ca.pem and ?tlsCAFile=ca.pem&tls=false. The spec should clarify if tls=false is intended to be an unconditional override.

Test coverage gap

"uri-options/tests/tls-options.json" contains no test of implicit enablement. Fixtures across uri-options and connection-string assert a resulting tls or ssl value, and every one of them supplies tls= explicitly in the URI:

mongodb://example.com/?tls=true&tlsCAFile=ca.pem&tlsCertificateKeyFile=cert.pem
mongodb://example.com/?tls=true&tlsDisableOCSPEndpointCheck=true
mongodb://example.com/?tls=true&tlsDisableCertificateRevocationCheck=false
…

Fixtures assert only a bare tls-prefixed option and omit tls from their options map, so the runner never checks it.
Consequence: any driver could change its implicit-TLS behavior in either direction.

Why this matters

• Portability. The same connection string may yield an encrypted connection in one driver and a plaintext one in another. Connection strings are routinely copied between applications written in different languages.
• It is a security-relevant outcome, not a formatting detail. Users reason about whether their traffic is encrypted, and the answer currently depends on which driver reads the string and, potentially, on option ordering within it.

Motivation

Who is the affected end user?

• Application developers connecting to deployments over TLS via a connection string, especially teams sharing one connection string across services written in different drivers.
• Driver maintainers, who carry an undocumented and untested behavior.

How does this affect the end user?

The end user might be confused.

How likely is it that this problem or use case will occur?

Edge case. Requires a connection string that omits tls= while carrying a tls-prefixed option.

If the problem does occur, what are the consequences and how severe are they?

It might have a security-relevant outcome.

Is this issue urgent?

No

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

No

Acceptance Criteria

• Decide whether the spec should define a normative rule: a plausible candidate being "options that supply TLS material enable TLS; options that only modify TLS behavior do not", or remain permissive and rely on the documentation requirement.
• Add "tls-options.json" coverage pinning the resulting tls value for representative options, including at least one bare behavior-modifier option and one explicit tls=false alongside an implying option. If the spec stays permissive, these may need to be driver-configurable expectations rather than fixed ones.

If a normative rule is adopted, any driver that has to change behavior would be downgrading or upgrading a connection's transport, so the change belongs in a major release with an explicit release note.