Re: [TLS] Trust Expressions Follow-up

[David Benjamin <[e-mail]>]

Hi Orie,

Thanks for the note! I'm not very familiar with the SCITT work, so I can't
speak to it directly. But perhaps I can try to describe what we're trying
to achieve for TLS, and that might help you determine whether it applies to
SCITT?

We're looking here to address problems caused by single-certificate
deployment models in TLS. In an ecosystem where one server may serve many
diverse clients (ranging from evergreen browsers, to decade-old TV set-top
boxes) with different requirements, that deployment model results in a ton
of conflicts as the PKI evolves to meet user security needs. The first
message in this thread, and this document
<https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md> try
to describe the problem and goals a bit.

TLS, being an online protocol, lends itself well to negotiation-based
solutions (we do it for cipher suites, etc.), where the server has multiple
certificates available and then somehow the client and server are able to
determine which to use. Trust expressions aim to provide that "somehow".
The manifests business is purely a supporting structure to get there, since
we need to be able to succinctly describe what are fairly large lists of
trusted CAs in many PKIs. If there isn't an analogous deployment problem or
online protocol in SCITT, the work probably isn't directly applicable.

I didn't quite follow the transparency service comments (this may be my
unfamiliarity with SCITT again), but this draft isn't trying to change PKI
structure. Or rather, it isn't trying to do so directly. Having a robust
negotiation mechanism *enables* us to explore structural changes. I do
think that will be valuable, as post-quantum dramatically changes some
trade-offs here. (Signatures and keys are now *huge*.*)* E.g. there's the
intermediate elision use case you noted. But that one isn't related to
transparency and is simply observing that intermediate elision and
short-lived trust anchors are the same thing.

We do have another draft, draft-davidben-tls-merkle-tree-certs, which
explores a much more differently structured PKI, aiming to fit with how the
Web PKI currently does transparency. Though we wrote that draft first and
have not yet had time to rebase it atop trust expressions. There are
probably other data points in this design space too, and I hope certificate
negotiation will help us find the right ones for various use cases.

David

On Fri, Mar 1, 2024 at 6:39 PM Orie Steele <[e-mail]>
wrote:

> I found the CDDL in the appendix intriguing:
>
>
> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#appendix-A
>
> In SCITT, we've been kicking around a related concept...
> It's had several names, all of which have led to confusion, so I will not
> repeat them here, but I want to overlay how they have been related in SCITT:
>
> trust-anchor = { ; cose sign1 of some key (JWK/PGP/COSE) or certificate
>     type: text,
>     * text => any,
> }
>
> trust-store-entry = { ; a receipt from a transparency service, proving a
> trust anchor in included in a log (like CT/KT)
>     id: text,
>     labels: [+ uint],
>     max_lifetime: uint,
>     * text => any,
> }
>
> trust-store-version = { ;  an aggregation of receipts, based on some
> query, for example, all receipts for trust anchors signed by the same key.
>     timestamp: int,
>     entries: [+ trust-store-entry],
>     * text => any,
> }
>
> trust-store-manifest = { ;  cose sign 1 of an aggregation of receipts,
> related to some subject, for example, a software bill of materials, where
> each receipt is for a specific software dependency
>     name: text,
>     max_age: uint,
>     trust_anchors: {+ text => trust-anchor},
>     versions: [+ trust-store-version],
>     * text => any,
> }
>
> One of the interesting topics we have discussed is producing stable
> identifiers for these structures, building on URI templates and thumbprints.
>
> In the examples I can see in the trust expressions draft, you have data by
> value instead of data by reference.
>
> Consider the following URI Template for expressing versions of a trust
> store:
>
> https://{service-provider}/{trust-store-manifest.name}/versions -> all
> versions of a trust store by name
> https://{service-provider}/{trust-store-manifest.name}/versions/1672531200
> -> all receipts for certs in a trust store version (certs by reference) ->
> list of signatures ( certs by value )
>
> We had wondered if it would be valuable to assign a naming convention and
> content addressed names to resources,
> so that you could ask an arbitrary scitt transparency service for details
> regarding any artifact that you might be holding as bytes.... for example:
>
> https://{service-provider}/{trust-store-manifest.name}/trust_anchors/{thumbprint(A1)}
> ->  all versions of a trust store by name containing A1.
>
> Obviously these names are not cross protocol friendly, we looked into URNs
> for that (don't throw things at me, I know this is a sensitive subject in
> the IETF).
>
> The concept of SCITT Receipts seems close to the purpose of intermediate
> ellison here:
> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-intermediate-elision
>
> The idea was that if you had stable receipts from a transparency service
> you trusted, you might not need to care about all the parts of a cert chain
> that they validated before including the cert in their transparency log.
>
> I'd be interested in prototyping a SCITT mapping for this, if I can wrap
> my head around the use case a bit more.
>
> OS
>
>
>
>
>
> On Thu, Feb 29, 2024 at 6:31 PM David Benjamin <[e-mail]>
> wrote:
>
>> Oh, I should have added: I put together an informal "explainer"-style
>> document to try to describe the high-level motivations and goals a bit
>> better. The format is adapted more from the web platform end, which likes
>> to have separate explainer and specification documents, but it seemed a
>> good style for capturing, at a high level, what we're trying to accomplish.
>> https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md
>>
>> It's largely a copy of the start of this email thread, but I figured it'd
>> be useful to have a more canonical home for it. (We'll probably adapt some
>> of that text back into the draft, after some more wordsmithing.)
>>
>>
>> On Thu, Feb 29, 2024 at 7:18 PM David Benjamin <[e-mail]>
>> wrote:
>>
>>> Circling back to this thread, we're now looking at prototyping the TLS
>>> parts in BoringSSL, on both the client (Chrome) and the server side. Let us
>>> know if you have any thoughts on the proposal!
>>>
>>> (Nothing that would prevent us from changing details, of course. But as
>>> there are a lot of pieces here, we'd like to get some experience with
>>> things.)
>>>
>>> On Thu, Jan 25, 2024 at 5:00 PM David Benjamin <[e-mail]>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Now that the holidays are over, I wanted to follow up on
>>>> draft-davidben-tls-trust-expr and continue some of the discussions from
>>>> Prague:
>>>>
>>>>
>>>> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html
>>>>
>>>>
>>>> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-tls-trust-expressions-00
>>>>
>>>> First, I wanted to briefly clarify the purpose of excluded_labels
>>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-trust-expressions>:
>>>> it is primarily intended to address version skew: if the certificate is
>>>> known to match (example, v10) and the client says (example, v11), the
>>>> server doesn’t know whether v11 distrusted or retained the CA. We resolve
>>>> that with a combination of excluded_labels and TrustStoreStatus.
>>>> excluded_labels is not intended for user-specific removals. I’ve
>>>> reworked the Privacy Considerations
>>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations>
>>>> section to discuss this more clearly.
>>>>
>>>> Second, I wanted to take a step back and try to better articulate our
>>>> goals. I think the best way to look at this draft is in three parts:
>>>>
>>>> 1. A new multi-certificate deployment model (the overall goal)
>>>>
>>>> 2. Selecting certificates within that model (the TLS parts of the draft)
>>>>
>>>> 3. Provisioning certificates (the ACME parts of the draft)
>>>>
>>>> We’d most like to get consensus on the first, as it’s the most
>>>> important. Trust expressions are a way to achieve that goal, but we’re not
>>>> attached to the specific mechanism if there’s a better one. We briefly
>>>> discuss this in the introduction
>>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-introduction>,
>>>> but I think it is worth elaborating here:
>>>>
>>>> The aim is to get to a more flexible and robust PKI, by allowing
>>>> servers to select between multiple certificates. To do this, we need a way
>>>> for the servers to reliably select the correct certificate to use with each
>>>> client. In doing so, we wish to minimize manual changes by server operators
>>>> in the long run. Most ongoing decisions should instead come from TLS
>>>> software, ACME client software, and ACME servers.
>>>>
>>>> Why does this matter? PKIs need to evolve over time to meet user
>>>> security needs: CAs that add net value to the ecosystem may be added,
>>>> long-lived keys should be rotated to reduce risk, and compromised or
>>>> untrustworthy CAs are removed. Even a slow-moving, mostly aligned ecosystem
>>>> is still made of individual decisions that roll out to individual clients.
>>>> This means, whether we like it or not, trust divergence is a fact of life,
>>>> if for no other reason than out-of-date clients in the ecosystem. These
>>>> clients could range from unupdatable TV set-top boxes to some IoT device to
>>>> a browser that could not communicate with its update service.
>>>>
>>>> Today, the mere existence of old clients limits security improvements
>>>> for other, unrelated clients. Consider a TLS client making some trust
>>>> change for user security. For availability, TLS servers must have some way
>>>> to satisfy it. Some server, however, may also support an older client. If
>>>> the server uses a single certificate, that certificate is limited to the
>>>> intersection of both clients.
>>>>
>>>> At the scale of the Internet, the oldest clients last indefinitely. As
>>>> servers consider older and older clients, that intersection becomes
>>>> increasingly constraining, causing availability and security to conflict.
>>>> As a community of security practitioners, I wish I could tell you that
>>>> security wins, that those servers can simply be convinced to drop the old
>>>> clients, and that this encourages old clients to update. I think we all
>>>> know this is not what happens. Availability almost always beats security. The
>>>> result of this conflict is not that old clients get updates, it is that
>>>> newer clients cannot improve user security. It takes just one
>>>> important server with one important old client to jam everything, with
>>>> user security paying the cost.
>>>>
>>>> We wish to remove this conflict with certificate negotiation, analogous
>>>> to TLS version negotiation and cipher suite negotiation. Certificate
>>>> negotiation, via trust expressions, means security improvements in new
>>>> clients do not conflict with availability for older clients. Servers can,
>>>> with the aid of their ACME servers, deliver different chains to different
>>>> clients as needed.
>>>>
>>>> Now, some of these problems can be addressed with cross-signs between
>>>> CAs, but this is a partial solution at best. Without negotiation, this
>>>> still means sending certificates for the lowest common denominator to all
>>>> clients. This wastes bandwidth, particularly with post-quantum
>>>> cryptography, where every signature costs kilobytes. Additionally, an
>>>> individual server operator cannot unilaterally configure this. Cross-signs
>>>> apply to entire intermediate CAs, not just the individual server’s
>>>> certificate.
>>>>
>>>> There’s more to say on this topic, as relieving this conflict solves
>>>> many other PKI problems and enables new solutions for relying parties, CAs,
>>>> and subscribers. We discuss some of these in the use cases
>>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-use-cases>
>>>> section. But hopefully this helps clarify our goals and is a starting point
>>>> for discussion.
>>>>
>>>> We’d be interested to hear thoughts on these issues or others. Our hope
>>>> is to reach enough consensus on the list to determine whether it would make
>>>> sense to have a call for adoption around Brisbane.
>>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
>>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>