Hi Christian, Thanks for the thoughts!
By TLSA usage value 0, you mean this thing? https://www.rfc-editor.org/rfc/rfc7671.html#section-5.4 Skimming it, I think it does not *quite* do what our draft had in mind. That record seems to be something along the lines of certificate pinning, where a trusted DNS record tells you a list of CAs you can accept for the name. We were looking to solve the converse problem, where DNS is untrusted, the client already has some trust anchors, and we need to ask the server to serve the particular certification path that satisfies the client. That way one server can serve clients with different trust lists. (E.g. older and newer versions of the same client, or a server that spans multiple kinds of applications with more wildly different needs, such as perhaps browsers vs the sorts of clients you're thinking of.) I guess the other factor is that, for the kinds of applications we were looking at, HTTPS/SVCB is already a record that folks are fetching for this kind of metadata, and has had a lot of work put into it w.r.t. how to solve, e.g., multi-CDN deployments. (That was a huge concern of folks around the ECH days.) So using that record plugs into all that, as well as any future work about better automating that record on the server side, like draft-ietf-tls-wkech. Given those differences, my sense is HTTPS/SVCB is still a better fit for this kind of not-necessarily-trusted selection hint, where TLSA seems to be more about directly anchoring the TLS key into a trusted DNS. (Of course, this is just a starting point. Perhaps the WG will go in a different direction altogether. There's a whole space of solutions here, with varying dependencies on DNS, etc. E.g. if we can come up with other encodings for what can fit in the ClientHello initially.) Still, it's good to hear about how other applications use PKI-like constructions. I think, in the excitement about debating abstract concepts like "convergence" and "divergence", we tend to lose sight of the cases when different applications do indeed have different needs, including around the PKI. David On Wed, Feb 5, 2025 at 9:54 AM Christian Amsüss <christ...@amsuess.com> wrote: > Hello tls-trust-anchor-ids authors, > > I'm working on a similar document[1] in a different area (in applications > without WebPKI and TLS), where just like here, eventually there might be > SVCB record would contain hints as to who the relevant trust anchors > are. > > In our work we're so far open as to whether data would be transported in > SVCB records, or whether we'd rather emulate the path taken by DANE with > TLSA records. > > Could you share a bit of the reasoning why the trust-anchor-ids document > goes with SVCB records tather than using TLSA values with usage value 0 > (trust anchor with PKIX validation)? > > Thanks > Christian > > [1]: https://datatracker.ietf.org/doc/draft-lenders-core-dnr/ > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
