Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt
This is very awesome. Just some quick thoughts: This extension seems very useful in internal environments with their own proprietary PKI. The first bullet in the intro does get at this, but I think it still undersells just how compelling this extension would be. FSIs/Banks, Governments, technology companies often have CAs with validities in short durations and have to perform rotations very often. This extension makes that so much more manageable and safer. I think there's a strong internet stability argument here ... many large outages of organizations have been caused by mishandling these rotations. In the security / privacy considerations: 1. Since this extension can appear in the CH in the clear, should we consider the case where network operators may use it to "enforce" support of particular trust anchors? For example, a firewall may reject connections based on anchors that do or don't support. and 2. Is this another fingerprint, at least at system level? For example; corporate user's whose organizations who add their own TAs may become finger-printable as coming from those organizations. Why sort TrustStores first by name-length, and then lexicographically? Just seems a little unnecessarily complex and unfriendly to indices. On Thu, Oct 19, 2023 at 8:38 AM David Benjamin wrote: > > Hi all, > > We just published a document on certificate negotiation. It's a TLS > extension, which allows the client to communicate which trust anchors it > supports, primarily focused on use cases like the Web PKI where trust stores > are fairly large. There is also a supporting ACME extension, to allow CAs to > provision multiple certificate chains on a server, with enough metadata to > match against what the client sends. (It also works in the other direction > for client certificates.) > > The hope is this can build towards a more agile and flexible PKI. In > particular, the Use Cases section of the document details some scenarios > (e.g. root rotation) that can be made much more robust with it. > > It's very much a draft-00, but we're eager to hear your thoughts on it! > > David, Devon, and Bob > > -- Forwarded message - > From: > Date: Thu, Oct 19, 2023 at 11:36 AM > Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt > To: Bob Beck , David Benjamin , Devon > O'Brien > > > A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been > successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-trust-expr > Revision: 00 > Title:TLS Trust Expressions > Date: 2023-10-19 > Group:Individual Submission > Pages:35 > URL: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt > Status: https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr > > > Abstract: > >This document defines TLS trust expressions, a mechanism for relying >parties to succinctly convey trusted certification authorities to >subscribers by referencing named and versioned trust stores. It also >defines supporting mechanisms for subscribers to evaluate these trust >expressions, and select one of several available certification paths >to present. This enables a multi-certificate deployment model, for a >more agile and flexible PKI that can better meet security >requirements. > > > > The IETF Secretariat > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt
Thanks for the comments! Responses inline. On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara wrote: > Some quick thoughts: > > - The multiple certificates from one ACME order really scares me. It > seems to me that can lead to all sorts of trouble. > Certainly open to different mechanisms, though could you elaborate on the trouble? We started with this one because it's actually just fixing a mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit: The server MAY provide one or more link relation header fields [RFC8288] with relation "alternate". Each such field SHOULD express an alternative certificate chain starting with the same end-entity certificate. This can be used to express paths to various trust anchors. Clients can fetch these alternates and use their own heuristics to decide which is optimal. https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 Whether anyone has ever used this, I don't know. The "and use their own heuristics to decide which is optimal" bit is quite absurd. :-) Relative to that, all we've done is: - Go ahead and define some format for a chain + properties... I like PEM much, but hey if ACME does that, we can just mimick that. - Fix the heuristic. You don't need heuristics when you have robust negotiation. But I suspect we'll want to define one where you make multiple orders too. That would probably work better for, e.g., Merkle Tree certs where the two issuances complete at very different times. But then, conversely, when the two paths actually share an end-entity certificate, I imagine a single order would be better so the CA knows it only needs to generate one signature. And then when they don't share an end-entity certificate but are similar enough in lifetime and issuance time, either seems fine, so we figured this was a reasonable starting point. > - If there can be only one certificate, one could send all the chains > in one go via fist sending the certificate, then issuer chains each > ended by entry describing the trust anchor. > I'm not quite sure if I've parsed this right, but are you thinking of one file that somehow describes all alternatives together? That's plausible too. Like I said, we mostly did this one because ACME already did it, so we inferred that was The ACME Way. :-) > - The latest version and previous version stuff seems pretty confusing > to me. > Yeah, it took us many iterations to find a good way to describe it, and I'm sure we haven't gotten it right yet. It's all to deal with version skew cleanly, when the relying party references a newer trust store than what the subscriber knew about at the time the certificate was issued. Since it seems your suggestion below relates to this, maybe some of the discussion below will help us clear it up and get to a better description? > - I am not sure this is useful for the client->server direction. > Eh, it costs ~nothing to define it in both directions, just a global s/client/relying party/ and s/server/subscriber/ across the document. :-) I figure we may as well define it in both directions, and if some client certificate deployments find it useful, cool. On the Chrome side, if the operating systems could give us something like this, with pre-made paths and unambiguous rules for when to send each, I would be overjoyed. We spend quite a lot of time helping people debug misconfigurations and quirks around client certificate selection. > What I think is a simpler version that might work: > > > Information from root program to CA: > > - Root program name. > - For each trust anchor: > * Trust anchor certificate. > * First version TA appeared in. > * Expiry time > * List of indices. > > Indices can be reused after all TAs using those have expired. > > > Information from CA to TLS server for each TA: > > - For each root program: > * Root program name > * The first version TA appeared in. > * List of indices. > > CA MUST NOT include entries that expire before the certificate. > > > Information from TLS client to TLS server: > > - Root program name. > - Root program version. > - List of revoked indices. > > The revoked indices specifies TAs that have been recently removed > before expiry (there could still be unexpired certificates out > there). > > > Chain is usable if it includes an entry where: > > a) Root program name matches, AND > b) Root program version is at least the first version, AND > c) Intersection of indices and revoked indices is empty. > > If TLS server has multiple configured certificates, it should skip ones > that have no usable chains. If no certificate has usable chain, it > should act like the extension was not sent. > If I'm parsing this right, I think the main issue here is this presumes a removed CA will stop issuing certificates: Suppose some CA is in v2 and then was removed in v3. We need to ensure certificates issued by that CA don't match a v3 client, so the server will send a different one. Immediately after removal,
Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt
On Fri, Oct 20, 2023 at 4:07 PM David Benjamin wrote: > Thanks for the comments! Responses inline. > > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara > wrote: > >> Some quick thoughts: >> >> - The multiple certificates from one ACME order really scares me. It >> seems to me that can lead to all sorts of trouble. >> > > Certainly open to different mechanisms, though could you elaborate on > the trouble? We started with this one because it's actually just fixing a > mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit: > >The server MAY provide one or more link relation header fields >[RFC8288] with relation "alternate". Each such field SHOULD express >an alternative certificate chain starting with the same end-entity >certificate. This can be used to express paths to various trust >anchors. Clients can fetch these alternates and use their own >heuristics to decide which is optimal. > > https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 > > Whether anyone has ever used this, I don't know. The "and use their own > heuristics to decide which is optimal" bit is quite absurd. :-) Relative to > that, all we've done is: > > - Go ahead and define some format for a chain + properties... I like PEM > much, but hey if ACME does that, we can just mimick that. > Sorry, I meant to write "I *don't* like PEM much". :-) > - Fix the heuristic. You don't need heuristics when you have robust > negotiation. > > But I suspect we'll want to define one where you make multiple orders too. > That would probably work better for, e.g., Merkle Tree certs where the two > issuances complete at very different times. But then, conversely, when the > two paths actually share an end-entity certificate, I imagine a single > order would be better so the CA knows it only needs to generate one > signature. And then when they don't share an end-entity certificate but are > similar enough in lifetime and issuance time, either seems fine, so we > figured this was a reasonable starting point. > > >> - If there can be only one certificate, one could send all the chains >> in one go via fist sending the certificate, then issuer chains each >> ended by entry describing the trust anchor. >> > > I'm not quite sure if I've parsed this right, but are you thinking of one > file that somehow describes all alternatives together? That's plausible > too. Like I said, we mostly did this one because ACME already did it, so we > inferred that was The ACME Way. :-) > > >> - The latest version and previous version stuff seems pretty confusing >> to me. >> > > Yeah, it took us many iterations to find a good way to describe it, and > I'm sure we haven't gotten it right yet. It's all to deal with version skew > cleanly, when the relying party references a newer trust store than what > the subscriber knew about at the time the certificate was issued. Since it > seems your suggestion below relates to this, maybe some of the discussion > below will help us clear it up and get to a better description? > > >> - I am not sure this is useful for the client->server direction. >> > > Eh, it costs ~nothing to define it in both directions, just a global > s/client/relying party/ and s/server/subscriber/ across the document. :-) I > figure we may as well define it in both directions, and if some client > certificate deployments find it useful, cool. On the Chrome side, if the > operating systems could give us something like this, with pre-made paths > and unambiguous rules for when to send each, I would be overjoyed. We spend > quite a lot of time helping people debug misconfigurations and quirks > around client certificate selection. > > >> What I think is a simpler version that might work: >> >> >> Information from root program to CA: >> >> - Root program name. >> - For each trust anchor: >> * Trust anchor certificate. >> * First version TA appeared in. >> * Expiry time >> * List of indices. >> >> Indices can be reused after all TAs using those have expired. >> >> >> Information from CA to TLS server for each TA: >> >> - For each root program: >> * Root program name >> * The first version TA appeared in. >> * List of indices. >> >> CA MUST NOT include entries that expire before the certificate. >> >> >> Information from TLS client to TLS server: >> >> - Root program name. >> - Root program version. >> - List of revoked indices. >> >> The revoked indices specifies TAs that have been recently removed >> before expiry (there could still be unexpired certificates out >> there). >> >> >> Chain is usable if it includes an entry where: >> >> a) Root program name matches, AND >> b) Root program version is at least the first version, AND >> c) Intersection of indices and revoked indices is empty. >> >> If TLS server has multiple configured certificates, it should skip ones >> that have no usable chains. If no certificate has usable chain, it >> should act like the extension was not sent. >> > > If I'm parsing this rig
