[TLS]Re: Consensus Call: -rfc8446bis PRs #1357
> On Jun 13, 2024, at 18:42, Salz, Rich wrote: > > I looked at the diff in https://github.com/tlswg/tls13-spec/pull/1357/files > > The changes are fine with me and I prefer EKR's wording about close_notify. > Does that need to be added to section 1.2? Ah yes, we should note this (and the other post WGLC changes) in s1.2! Might get done as a separate PR though. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS trust expressions and certificate_authorities
On Thu, Jun 13, 2024 at 4:23 PM Amir Omidi 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 . 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 wrote: > >> >> >> On Wed, Jun 12, 2024 at 5:16 PM Nick Harper wrote: >> >>> On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson >>> wrote: >>
[TLS]Re: TLS trust expressions and certificate_authorities
> 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 wrote: > > > On Thu, Jun 13, 2024 at 4:23 PM Amir Omidi 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 . 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. a
