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

[David Benjamin <[e-mail]>]

Hi Rich,

Have you read the second draft (draft-beck-trust-anchor-ids)? I think it's
conceptually much simpler overall and is hopefully easier to wrap one's
head around. There's no JSON structure or relying party / root program
split or anything.

The complexity of trust expressions doesn't come from the scope of the
mechanism, or any of the things being discussed in this thread. It's simply
the result of us trying to engineer around versioning lists of things.
Somehow the server needs to correctly interpret ClientHellos from clients
that are newer than its certificate, despite trust stores adding and
removing CAs over time. That means needing to establish invariants across
versions and rules for how both sides work with those invariants.

That design, in turn, came from a desire to minimize server operator burden
above all else. In most TLS ecosystems, there are far fewer root programs
and CAs than server operators. So keeping the communication flow unchanged
for server operators (static blob of data from the CA that one can
deterministically interpret) is valuable. But the cost of doing so was to
introduce a lot of coordination between root programs and CAs. Those
entities are fewer and already need to coordinate, but it does sadly make
the complete picture more complex.

The other draft makes different tradeoffs in the course of solving the same
problem. (As they are the same problem, most of the discussions of the
goals and their implications are the same). It increases the server
operator burden (a DNS extension in an ideal deployment), but we then
remove this messy notion of "trust stores" and some of the limitations it
implies on what the client can express. The overall system is simpler and,
I think, much easier to understand.

At the end of the day, the immediate problem both drafts target is quite
simple: arrange for the server to pick a certificate path from one of the
CAs that the client trusts. It's the same as every other parameter
negotiation problem in TLS.

You're right to observe we have a broad range of use cases in mind for this
problem. However those come from the problem being solved, not individual
pieces of the solution. Trust anchor negotiation problem is *the* essential
problem when TLS intersects with PKIs. Removing use cases isn't going to
simplify the mechanism. Indeed I think this is exactly the sign of
targeting the right problem: a single primitive with a simple goal that is
naturally applicable to a broad range of use cases in the problem space.
(Cf how cipher suite negotiation can be used for a broad range of TLS
transitions, or TCP's stream abstraction fits many protocols.)

Hope that helps,

David


On Fri, Jul 19, 2024, 23:58 Salz, Rich <rsalz=[e-mail]>
wrote:

>
>    - I've read it before. I the main issue is that it says "trusted" a
>    lot.
>
>
>
> Yeah, kinda snippy but not necessarily wrong.
>
>
>
> I’m a little skeptical of approaches that solve an entire problem space
> with one architecture. I’m more skeptical of enough people having the
> ability to read and understand the semantics of several pages of JSON
> object descriptions. I know I got MEGO[1] a copule of times while reading
> it.
>
>
>
> Can we simplify things and solve just one problem?
>
>
>
> For example, in some off-line discuissions others have mentioned that with
> PQ signatures being so big, there are policy decisions that clients might
> want to enforce – do you need SCT’s? Do you want OCSP stapling? Maybe it
> will be worthwhile to just think about what kind hybrid/PQ policies clients
> will want to express?
>
>
>
> [1] https://www.collinsdictionary.com/dictionary/english/mego
>
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>