> > Of course this is possible in theory, there are no standards police, but > this argument overlooks the gargantuan technical and economic costs of > deploying this kind of private extension. You'd need to convince a diverse > population of implementers on both the client and server side to adopt and > enable your thing. >
I don't believe my hypothetical private extension would need to be adopted by any servers, just clients. And due to power laws, adoption by one or two clients would provide visibility into a substantial section of Internet traffic. Can you expand on how this draft enables the more rapid distrust of failed > CAs? > This is described in more detail in section 9.1 of the draft. Currently we have the problem that, as long as any older RP relies on a given root, subscribers have to keep using it, which means newer RPs have to keep trusting it. I'm confused by this remark. Are there clients which would tolerate a > certificate if only it had a longer lifetime? Is there any circumstance in > which you would have both a long-life and short-life certificate available, > and you would prefer to serve the long-life cert? > Yes, especially when you push to shorter and shorter lifetimes (say, 1 day, 1 hour), you start to have the issue that not all clients will have sufficiently accurate clocks to verify them. Clients with accurate clocks can advertise support for a root that issues short-lived certs while clients that don't will not advertise support for this root, and with TE we can support both. On Tue, Apr 30, 2024 at 3:57 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote: > Hi Brendan, Bas, > On 30/04/2024 05:17, Brendan McMillion wrote: > > It seems like, with or without this extension, the path is still the same: > you'd need to force a browser to ship with a government-issued CA > installed. Nothing about this makes that easier. It /is/ somewhat nice to > already have a way to signal that a given client does/doesn't support the > government CA -- but you could just as easily do this with a simple > extension from the private range, so I'm not sure that was a big blocker. > > On 30/04/2024 09:13, Bas Westerbaan wrote: > > No need for a new extension: a government can use a specific signature > algorithm for that (say, a national flavour of elliptic curve, or a > particular PQ/T hybrid). > > Of course this is possible in theory, there are no standards police, but > this argument overlooks the gargantuan technical and economic costs of > deploying this kind of private extension. You'd need to convince a diverse > population of implementers on both the client and server side to adopt and > enable your thing. This draft if widely implemented as-is would effectively > solve that problem for governments by removing a huge architectural > roadblock. This is the power of the IETF and why decisions about what TLS > extensions to adopt are important. Mark Nottingham has a longer piece > <https://www.mnot.net/blog/2023/11/01/regulators> on this view. > > On 30/04/2024 05:17, Brendan McMillion wrote: > > On the other hand, this draft solves a number of existing security issues, > by allowing more rapid distrust of failed CAs, > > Can you expand on how this draft enables the more rapid distrust of failed > CAs? > > The roadblock to faster distrust has always been how quickly subscribers > of the failed CA are able to migrate. ACME makes this process much easier, > but still requires server operators to reconfigure their ACME clients. This > draft doesn't improve that situation. > > An effective technique long-used by Microsoft and Mozilla when distrusting > CAs is to ship a distrust-certs-issued-after signal rather than an > immediate distrust of all issued certificates. This allows server operators > to gradually migrate in line with their usual schedule of certificate > renewals rather than forcing a flag day on the world. I understand that at > least one further major root program is looking at supporting the same > feature. > > by allowing clients to signal support for short-lived certificates, etc. > > I'm confused by this remark. Are there clients which would tolerate a > certificate if only it had a longer lifetime? Is there any circumstance in > which you would have both a long-life and short-life certificate available, > and you would prefer to serve the long-life cert? > > Best, > Dennis > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
