I'm not sure what I think about adoption, but maybe it rounds to yes. At the interim I think I said (although I can't remember if I said or typed it snarkily in a backchannel) that just because problems are worth solving doesn't mean we can solve them. I'm afraid this is one of them.
For the specific case of devices with long lifetimes and short updates, sending the CA in the already existing channel ought to work. The problem with trust anchors is it requires some far reaching changes impacting all server software, TLS implementations, client software, server operations, ACME clients, and maybe DNS as well. That ain't happening to a first approximation. Perversely, the implementors best suited to do this are the ones that we need to adopt this the least. At the same time I think that we have a very real "just works in Chrome" problem that negotiation would enable. We've already seen CAs pay more attention to Google and Apple than Mozilla in dealing with incidents. Older proposals where it would have just been an anchor the server needs to know how to deal with would have had all the fun of User Agent capability negotiation. I'm glad to see this proposal at least on a first glance avoids much of that. I do think there are some changes that can fix some of the ubiquity issues, in approximate reverse order of my confidence in them: - Use a hash of the root certificate as an identifier. Do something really clever/stupid depending on perspective to shrink it. This way servers have a fighting chance of figuring out what it is without additional configuration. - Use DNS as an initial hint, not a mandatory field (maybe in draft-beck, not sure) - HRR for when client hello's don't have a right one, so servers can fix busted DNS. - wildcard by client, for cases where DNS doesn't have any info to learn the server config - Some guidance on how to cache this. I do think I need to think more, and I'm definitely not sure we'll eventually solve this, although I'm optimistic enough we can start here. However, if the benefit requires near universal adoption with some really far reaching systemic impacts, I don't think publication would be warranted. Sincerely, Watson On Wed, Jan 15, 2025 at 8:00 AM Joseph Salowey <j...@salowey.net> wrote: > > At the trust tussle Interim in October we had consensus that the working > group was interested in working on the following problem: > > > “Avoid client trust conflicts by enabling servers to reliably and efficiently > support clients with diverse trust anchor lists, particularly in larger PKIs > where the existing certificate_authorities extension is not viable” > > > After IETF 121, we asked for submissions for possible working group adoption > as a starting point for this work. We received two submissions: > > > [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03 > > [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 > > > [1] defines a new protocol mechanism, while [2] provides an explanation of > why the mechanism in [1] may not be needed and may be problematic. Since the > second draft does not define a protocol mechanism we are not considering it > for adoption, but we request that working group members review both documents > and use [2] as input into determining whether we should adopt [1] as a > working group item. Adoption as a working group item means the working group > has change control over and can modify it as necessary; an adopted document > is only a starting point. Please respond to this thread if you think the > document should be adopted as a working group item. If you think the document > is not appropriate for adoption please indicate why. This adoption call will > close on February 7, 2025. Also please remember to maintain professional > behavior and keep the discussion focused on technical issues. > > > Thanks, > > > Sean, Deirdre and Joe > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
