> If this is implemented by user agents, how do we envision the fingerprinting impact for this?
The privacy considerations section discusses this a little bit: https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations Broadly, the fingerprinting story is the same as the certificate_authorities extension, in that trust expressions targets the cases where the trust anchor list is common to your desired anonymity set, whatever it is. That's a pretty large space of scenarios, though it does exclude some scenarios where PKI agility may still be valuable. (But we're certainly open to exploring solutions that are more widely applicable!) David On Fri, Jun 14, 2024 at 4:54 PM Bob Beck <bbe=40google....@dmarc.ietf.org> wrote: > > > On Thu, Jun 13, 2024 at 4:23 PM Amir Omidi <amir= > 40aaomidi....@dmarc.ietf.org> wrote: > >> I’ve had a lot of trouble understanding how the user agent is supposed to >> be configured with this. Maybe a browser is going to be able to do it >> easily, but how do we envision this working in openssl? Or a programming >> language? >> >> If this is implemented by user agents, how do we envision the >> fingerprinting impact for this? >> >> My comments aren’t blockers by any means. It’s only me trying to >> understand how we imagine this draft working in these various TLS client >> implementations. >> > > Hi Amir. > > If you're thinking about "non-browser" things such as the openssl command > line tool, curl, nc, libcurl using utilities, etc. You probably need to > first ponder where those tools are getting their trust store to verify > certificates from the public web today. > > Sometimes this is a custom bundle included with the tool, sometimes this > is a "system" CA trust store maintained by the operating system > distribution. Either way "someone" decided to include it, and usually, this > is done by following along with an existing root program > that the maintainers mostly trust to do a good job of being a root > program. Hopefully it is kept up to date both in terms of adding new > additions, and keeping up with distrusts. > > By not sending a trust expression they could just continue as today, and > in the presence of a trust expressions supporting server they would get the > "default" certificate that is hoped to be ubiquitous. In the near term > until trust expressions are well supported by TLS software and servers, I > would expect that to likely be what would happen. > > Outside of my day job I do assist with curating a trust store in an > operating system that is used by such tools when built there. Today we > mostly just follow along with Mozilla's trust store for firefox, because we > have no desire today to run our own root program. So let's call this > thankless task maintenance for "BasementOS". > > In the future, If support were added to the TLS libraries we use, a trust > expression *could* be used, assuming BasementOS had one to use. That could > take several forms: > > - BasementOS can use the published information from a root program > publishing trust expressions to include the same roots of trust, and they > simply advertise the exact trust expression corresponding to the roots > they include. (I.E. if they decide to follow the chrome root program, they > fetch the information from the chrome root progam, include chrome's roots > at version 1234 and send the trust expression of "chrome 1234"). With > support for using an identified trust store in the TLS software, one could > even ponder being able to download or update versions of a package that > included such roots and the trust expression for them. > - BasementOS could decide a particular root program is mostly ok, and > do just as the above, but exclude some roots they don't want or like in the > system trust bundle, so they send the same trust expression, but exclude > the roots they remove. (chrome 1234 with exclusions) > > Someone could also decide we really really want to start their own root > program, for <reasons>. Maybe they don't want to be what a major browser > is. One of the (unstated, and perhaps we should state it clearer) goals of > trust expressions is to allow for new root programs to be created. > > - BasementOS (or a collective of multiple OS's, packages, whatever) > could start a root program, and start coordinating with CA's to include > their trust expression in matching delivered certificate chains. Maybe some > CA's do, maybe some do not. In the interim BasementOS could start with an > existing trust store, remove what it doesn't like, and send that along > with it's nascent trust expression (chrome 1234 with exclusions) > (basementOS 12) Once enough CA's include a basementOS trust expression on > certificates, they could transition to using a BasementOS trust expression > - Perhaps if BasementOS itself is too tiny for this job, it bands > together in a collective with other like minded OS's / projects, etc. and > runs a collective root program, the same way. > > The important takeaway here is that even today *SOMEONE* is making > decisions somewhere about what roots such things trust when they make > connections. Trust expressions do not change that. If today they are > manually curating a bundle without a trust expression, they can continue to > do so. If they are "following" a major root program that starts to publish > trust expressions, they could also send an appropriate trust expression. > > Now, do people today put a lot of thought into what "root program" is > maintaining the trust bundle and how up to date it is for their command > line tools? I am unsure that it gets the attention it might warrant. > > -Bob > > > >> Amir Omidi (he/them) >> >> >> On Thu, Jun 13, 2024 at 22:16 Eric Rescorla <e...@rtfm.com> wrote: >> >>> >>> >>> On Wed, Jun 12, 2024 at 5:16 PM Nick Harper <i...@nharper.org> wrote: >>> >>>> On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson <i...@dennis-jackson.uk> >>>> wrote: >>>> >>>>> You can't argue that T.E. contains the functionality of >>>>> certificate_authorities as a subset, then conclude that having additional >>>>> functionalities makes it less risky. You would need to argue the exact >>>>> opposite, that T.E. doesn't contain the bad functionalities of >>>>> certificate_authorities. The risk associated with abuse of a feature is >>>>> not >>>>> in any way diluted by tacking on good use cases. >>>>> >>>> I'm not arguing that TE is a superset of certificate_authorities. I'm >>>> arguing that it's an incremental improvement over certificate_authorities. >>>> That is to say, certificate_authorities is a way for a relying party to >>>> indicate to a subscriber which CAs it trusts, and TE is another way to do >>>> the same thing. TE is an incremental improvement because it's solving the >>>> same problem but making different tradeoffs. To deploy the >>>> certificate_authorities extension, no extra machinery is needed past what's >>>> in the certificates, but that comes at a cost of a large number of bytes >>>> sent by the relying party. TE optimizes for size, at the cost of additional >>>> complexity and machinery involving additional parties. >>>> >>>> For the abuse scenario, TE makes it no easier than >>>> certificate_authorities (the size of advertising the single malicious CA >>>> isn't a concern, whereas it is a problem when it's a browser's entire trust >>>> store that's advertised), and TE adds additional deployment complexity >>>> compared to certificate_authorities, which lessens the risk. >>>> >>> >>> I'm not sure that this analysis is correct. The text in 8446 isn't >>> entirely clear, but I think the >>> best reading is that that "certificate_authorities" list is supposed to >>> be exhaustive: >>> >>> 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. >>> >>> ... >>> >>> authorities: A list of the distinguished names [X501] of acceptable >>> certificate authorities, represented in DER-encoded [X690] format. >>> These distinguished names specify a desired distinguished name for >>> a trust anchor or subordinate CA; thus, this message can be used >>> to describe known trust anchors as well as a desired authorization >>> space. >>> >>> I don't know how widely implemented this extension is, but I don't think >>> it's >>> obviously safe to send a subset of the list. >>> >>> -Ekr >>> >>> >>>> The takeaway here is that the risks associated with the abuse of Trust >>>> Expressions also exist with certificate_authorities. >>>>> >>>>> I wonder what such a trust store manifest would look like... [1] [2]. >>>>> There's at least one large player out there with a list of CAs ready to go >>>>> and all the necessary machinery in place. >>>>> >>>> Ready to go and do what?! >>>> >>>> If you're talking about the EU eIDAS QWAC trust list, those CAs were >>>> already trusted by browsers before the eIDAS regulations took effect, and >>>> eIDAS allows for their distrust and removal. Already, one CA [1] on that >>>> list is being distrusted by multiple [2] browsers [3]. Even if the EU has a >>>> published list of CAs that they could turn into a trust store manifest, >>>> this is a distraction from the point that with TE, abuse requires the >>>> cooperation (or compulsion) of more parties than with >>>> certificate_authorities. >>>> >>>> 1: https://eidas.ec.europa.eu/efda/tl-browser/#/screen/tl/AT/5/25 >>>> 2: >>>> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/XpknYMPO8dI/m/JBNFg3aVAwAJ >>>> 3: >>>> https://groups.google.com/a/ccadb.org/g/public/c/wRs-zec8w7k/m/G_9QprJ2AQAJ >>>> >>>> _______________________________________________ >>>> TLS mailing list -- tls@ietf.org >>>> To unsubscribe send an email to tls-le...@ietf.org >>>> >>> _______________________________________________ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-le...@ietf.org >>> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
