On Fri, Oct 20, 2023 at 2:15 PM Colm MacCárthaigh <c...@allcosts.net> wrote:
> 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. > Yeah, my colleagues on the server end have had their share of nightmares dealing with certificate transitions on Google properties. We like to talk about PKIs as if they're these big, consistent things, but once you actually get down to it, this fiction breaks down very fast. Relying parties vary a bit, and we should take that into account when designing systems. > 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. > Re (2), section 10 talks about this. It's hard to avoid saying what CAs you trust without, well, saying what CAs you trust. Which means you should only use this in contexts where you're willing to do that. For something like a web browser, I would expect that we'd by default only advertise the browser-vendor-managed roots. That only reveals what browser you're running, which is thoroughly revealed by the entire web. That does unfortunately leave browser-adjacent private PKIs in the fallback path, and so servers still need to divine which to use. It's no worse than the status quo, but it is a bit disappointing to leave that problem unsolved. One could imagine an enterprise policy for administrators to say "yes, I want robust negotiation and am willing to reveal this part of my clients' trust anchor list". Or perhaps one filtered down to a particular set of name patterns that will stay within an intranet? I dunno. One way or another though, I think this is kinda fundamental to trying to help the server pick certificates, at least for any solution that looks like the standard client-offer / server-select TLS flow. (I could imagine alternative solutions with different tradeoffs, like the server presenting a list and the client picking, though that will add different complications such as extra round-trips or dependency on a DNS record that may not be as accessible. But I think any solution like that should be separate work. If we find we need a couple of these, it's more moving parts, but there's no reason they can't coexist.) Re (1), I think this mostly falls out of (2) and where you try to use this. We're scoping this to the subset of your trust anchor list that you *are* willing to reveal. In the browser-vendor-managed roots case, this ultimately just reveals what browser or browser family you are (which is already thoroughly revealed for better or worse). I won't speculate on what misguided network operators may try to filter on, but it wouldn't be a new capability. Happy to take a PR to add some extra text if you think it's worth talking about though. Additionally, any aspect of your trust anchor list that isn't revealed won't be affected. Ultimately, this doesn't change what the relying party *actually* accepts. This just allows the relying party to communicate something about it (just like, but more compactly than, the existing certificate_authorites extension) in hopes of better navigating this mess of sometimes overlapping but ultimately disparate PKIs. > Why sort TrustStores first by name-length, and then lexicographically? > Just seems a little unnecessarily complex and unfriendly to indices. > Do you mean in section 5.1? It was just arbitrary. I wasn't sure if "lexicographically", in IETF documents, was canonically defined to be length first or "a" before "ab" before "b". (Wikipedia seems to suggest there are variants <https://en.wikipedia.org/wiki/Lexicographic_order#:~:text=There%20are%20several%20variants%20and%20generalizations%20of%20the%20lexicographical%20ordering.%20One%20variant%20applies%20to%20sequences%20of%20different%20lengths%20by%20comparing%20the%20lengths%20of%20the%20sequences%20before%20considering%20their%20elements.>.) So I just picked a disambiguation that didn't take very many words to say. :-) But I'm fine with whatever order. The goal was to just pick *some* defined sort order, so that it's easy to find duplicates, and to hint that maybe you should put this into some structure that can binary search easily. Happy to do "a" before "ab" before "b" instead. Is there a canonical way to say that in IETF-ese without expending a lot of text? > On Thu, Oct 19, 2023 at 8:38 AM David Benjamin <david...@chromium.org> > 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: <internet-dra...@ietf.org> > > Date: Thu, Oct 19, 2023 at 11:36 AM > > Subject: New Version Notification for > draft-davidben-tls-trust-expr-00.txt > > To: Bob Beck <b...@google.com>, David Benjamin <david...@google.com>, > Devon O'Brien <asymmet...@google.com> > > > > > > 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
