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

[Dennis Jackson <[e-mail]>]

On 22/07/2024 12:28, Ilari Liusvaara wrote:

> I don't see TE requiring breaking API changes on client: API that lets
> one add a set of (pseudo) trust anchors plus TE advertisement for those
> should work?

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?

For example, applications which access the server certificate via a 
callback or after handshake completion are going to be surprised by 
anything non-X.509 and also likely differ in policy from the system 
trust store (making any use of the system root store's trust expression 
label by default quite troubling).

Similar issues apply for where applications configure the TLS 
certificate validation policy in advance, ship their own root store 
(even if its say a copy of an existing one) or hook up a custom 
certificate validation library.

> Server-side both require much more extensive API changes. However, I
> think that it is feasible to add support without breaking API changes
> (by extending certificate loading to support alternate issuer chains).

A similar picture seems to apply here. Adding a new API is fine but then 
needs server-side applications to opt in to using it. Otherwise 
overloading existing file / directory mechanisms might be possible if 
there's not too many fussy applications out there which are going to barf.

I'm pretty pessimistic about these API issues (Hyrum's Law etc) but I 
haven't had much exposure to OpenSSL's APIs from the perspective of 
other clients / servers - so curious if you do see a way to enable it by 
default without changing existing applications.

Best,
Dennis