Re: [TLS] Trust Expressions Follow-up

[Orie Steele <[e-mail]>]

Thanks for your thoughtful reply.

Inline:

On Sat, Mar 2, 2024 at 9:21 PM David Benjamin <[e-mail]> wrote:

> 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 think the SCITT analog here is managing code signing certs when trying to
verify a software bill of materials that covers both public and private CAs.


> 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.
>

This sorta lines up with the current solutions for short lived certs seen
in the wild today, such as Sigstore.

Is proving possession of an email address good enough to sign software?

What about scenarios with MFA, CI systems with certificates for each build
server, with HSM keys... etc.

It seems that there might be some conceptual alignment on "these certs for
this name, on these timescales", even if the certs are used for different
things.

SCITTs focus is to provide an access controlled audit log for details
related to the software supply chain.

I'm still trying to wrap my head around how
draft-davidben-tls-trust-expr maps to the CT use case (
https://datatracker.ietf.org/doc/rfc9162/), or how they might be related in
an ideal setting.

It seems like SCITT Receipts for a trust expression manifest might be a
thing, assuming you are trying to reason about which trust store manifests
that are used by a 3rd party, without the ability to talk to them
directly... Perhaps that's a "SCITT can help you audit how a trust store
was used" use case... or... maybe trust expressions help SCITT auditors
make quick sense of SCITT Receipts from PKIs that have aging identities
co-mingled with new ones, which seems to be common in software supply
chains.


> 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.
>

 Skimming the draft you mentioned, perhaps this is also a point of overlap
between your 2 drafts and the SCITT architecture:

https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs-01#section-10.3

You might build a "Merkle Tree certificate", using a SCITT transparency
service, since a SCITT receipt is logically an inclusion proof for a single
certificate,

A "signed feed of receipts" can be thought of as an intermediate data
structure for Merkle tree certs... possibly... I need more time to digest
the draft.

Thanks for your comments.


> 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>
>>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>