[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Dennis Jackson <[e-mail]>]

On 22/07/2024 16:06, Salz, Rich wrote:

> I agree adding a new API for T.E. which applications could opt in to 
> would be fine. But could T.E. ever be enabled by default without 
> breaking the existing API and requiring application changes?
>
> Yes it could. For example, you’d have to add meta-data identifying the 
> ‘directory of certs’ that are typically used so that it could become a 
> named trust store. Assume that’s a fixed filename, like 
> “trust-store-id.txt” or something. Then when you specify that 
> directory (e.g., via [1]) it could look for the fixed filename and 
> send that identifying information.
>
I agree that having a library like OpenSSL auto-discover the necessary 
metadata in the system root store is definitely possible. My concern is 
about breakage with the other parts of the API exposed to applications 
which will prevent T.E. from being able to be offered by default - 
meaning applications will have to opt-in via a new API.

The Trust Expression's extension is trying to convey accurate 
information about which certificates are acceptable (which is controlled 
by the application) and may change the certificate which is received 
(which is visible to the application). So I don't see how Trust 
Expression's could be enabled by default without breaking applications 
or the semantics of the Trust Expression's extension. Some examples:

  * Some applications will set their own certificate verification
    callback (SSL_CTX_set_cert_verify_callback). A Trust Expression's
    label cannot be sent with these connections because OpenSSL doesn't
    know what the policy is going to be that the application applies.
    Sending the T.E. label is informing the serve 'I will accept any
    certificate suitable for this root store'.
  * Some applications will use the default certificate verifier in
    OpenSSL, but then access the certificate chain via
    SSL_get_peer_cert_chain or similar functions for getting specific
    metadata. The application might then do further checks which OpenSSL
    is unaware of. If so, the Trust Expression's label from the system
    store cannot be used without making the label inaccurate.
  * Some applications will do use the default checks on the certificate,
    but access the certificate chain to consume / log / display the
    information elsewhere. It's likely these functions are going to
    expect a 'normal' X.509 cert chain but one of the use cases of Trust
    Expressions is to enable non-X509 certificate payloads or shorter
    chains.

I think the second and third cases are particularly critical. OpenSSL 
cannot know during the handshake whether the application is going to 
later call SSL_get_peer_cert_chain / SSL_get_peer_certificate and then 
make a decision about whether to tear down the connection. For example, 
the application may do its own pinning and check whether the issuer is 
acceptable.

In this case, if OpenSSL sent the Trust Expression extension with the 
label by default, it would be actively harmful, since the Trust 
Expression extension is telling the server "I will accept any cert valid 
in this root store" but in actuality the application is performing 
pinning. This would make the extension useless for the proposed use 
cases around handling pinning gracefully and giving server's confidence 
to migrate CAs.

So my conclusion is that TLS libraries are never going to be able to 
offer T.E. by default. Instead applications would have to opt in, which 
seems like a major barrier to adoption outside of browsers.

Happy to be corrected if there are some wrinkles here, but Hyrum's law 
seems pretty harsh for the existing TLS library APIs.

Best,
Dennis