Hello, I realize there has been extensive discussion about trust expressions and a variety of hypothetical scenarios that some believe will play out should this draft get adopted and implemented. I would like to start this out with a clear statement: we hear these criticisms and are paying very close attention to them in order to help ensure this working group does not ship an irresponsible standard that causes any of the possible doomsday scenarios sketched out. The crux of this disagreement isn’t whether the outlined hypotheticals are bad; we are in strong agreement on this point. Rather, the disagreement is about the causality being posited between a rather incremental extension mechanism and these outcomes. Here, we authors strongly disagree with the points that have been repeatedly mentioned by some working group members and I hope that a more careful analysis of what trust expressions actually provide over the status quo will help the working group work past these disagreements.
I believe that, in our excitement at the opportunities that a more agile web PKI can provide, we did ourselves and the broader community a disservice by leaning too far into some of the far-reaching possibilities we envision from a world with trust expressions. While we remain excited about a more agile and less-ossified PKI, it’s now clear that such emphasis caused the conversation to shift dramatically away from what the draft actually says and towards a variety of opinion-based arguments about what laws may be written by various world governments in the coming years and decades. Focusing on the actual draft text, the TLS trust expressions extension does not represent any kind of major paradigm shift, primarily due to its strong similarity to the existing certificate_authorities TLS extension. The difference between these extensions exists not in what information is being communicated, but rather, how concisely it’s being communicated. RFC 8446 defines the certificate_authorities extension as follows: “The "certificate_authorities" extension is used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection.” In practice, this means: - The supported certificate authorities are communicated by sending a list of DER-encoded distinguished names in the ClientHello and CertificateRequest messages - Subscribers match this set of distinguished names against their provisioned certificates and select one to serve - If no matching certificate exists, subscribers rely on some fallback heuristic for selection To more accurately describe what TLS trust expressions does and doesn’t do, I would like to discuss it in terms of its similarities and differences to certificate_authorities. Defined within trust expressions is: 1. A labeling and compression mechanism for the certificate_authorities TLS extension, also sent in the ClientHello and CertificateRequest messages, so that relying parties can more efficiently communicate this information to subscribers. With certificate_authorities, this is a list of trust anchor distinguished names. 2. A means of distributing this label information to subscribers so that they can extract trust anchor information from the aforementioned labels. With certificate_authorities, the labels are contained within the certificates themselves. 3. An algorithm for subscribers to match labels against a set of pre-provisioned TLS certificate paths. With certificate_authorities, this is a direct string match of listed distinguished names which must be searched for among provisioned certificates. 4. A mechanism to account for changes in trust between when subscribers obtain this information (certificate issuance) and when they evaluate a label (a TLS connection). This isn’t defined in certification_authorities because it’s not needed for the direct name matching used therein. There is no fundamental capability offered by trust expressions that isn’t already available by certificate_authorities. When compared to certificate_authorities, the primary obstacle being addressed by trust expressions is the size of the message sent in (1). X.501 distinguished names are notoriously verbose, and modern trust stores contain hundreds of trust anchors, rendering it infeasible for relying parties to dedicate tens of thousands of bytes in a TLS handshake to listing trust anchors. Notably, parties that may wish for clients to signal a specific mandated CA can do so efficiently with certificate_authorities today, as this requires sending only a single distinguished name. Compressing a set of trust anchor names can be done in a variety of ways, but trust expressions does so by applying a label and version scheme to trust stores (3), which are an existing and recognized collection of trust anchors that are also already relying party specific. The majority of complexity in trust expressions comes from (4). This complexity is a result of design choices made by the authors, but is also something that can change based on working group feedback and participation. We are far more committed to creating a usable mechanism for communicating supported trust anchors than we are any specific design choice. Critically, neither trust expressions nor certificate_authorities change what trust anchors are trusted by any relying party, whether they support these mechanisms or not. Discussion about whether some root program may be pressured to accept national trust anchors that do not meet existing standards is a critically important security policy topic, but is fundamentally orthogonal to this mechanism. Drawing causality between trust expressions and this outcome (especially ignoring the existing surface already provided by certificate_authorities) may be well-intentioned, but is misplaced. And lastly, to address some accurate critical feedback we’ve received, trust expressions do not “enable” a multi-certificate model. Today, web servers have a variety of options available to them to serve multiple TLS certificates, including fingerprinting TLS connections and the aforementioned certificate_authorities extension. Trust expressions do, however, offer some improvements by making trust signals both explicit and relatively concise. Language on this topic will be softened throughout our explainer and draft text. -Devon
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
