On 30/04/2024 16:13, Brendan McMillion 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.
This is just an observation that unilateral actions taken by major
players can screw things up for many people. It's true, but it has
little bearing on what we're weighing up here.
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.
This doesn't apply in case we're distrusting a CA because it's failed.
In 9.1 we're rotating keys. As I laid out in my initial mail, we can
already sign the new root with the old root to enable rotation. There's
no size impact to up-to-date clients using intermediate suppression or
abridged certs.
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.
Firefox already supports Delegated Credentials for exactly this use case
and which addresses clock skew, but DCs have never seen much use as far
as I know. In any case, this is an already solved problem.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
