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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
