On Tue, Apr 30, 2024 at 8:14 AM Brendan McMillion < brendanmcmill...@gmail.com> wrote:
> 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 the narrow point of shorter lifetimes, I don't think the right way to advertise that you have an accurate clock is to advertise that you support some set of root certificates. If we want to say that, we should have an extension that actually says you have an accurate clock. -Ekr > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
