> Yes, if one drops usecases that are valuable to simplify stuff, later > adding mechanism for those usecases ends up more complex than if one > had just gone with the originally more complex solution. > > And it might be worse than just supporting both: The features could > interact in bad ways. For example of bad interaction, certificate > compression versus certificate extensions. > > But on the other side there is excessive complexity from trying to solve > too much (e.g, certificate policies). Or worse, complexity that does not > serve any actual purpose (e.g., differing representations of IDNs in > email certificates). >
This is indeed the exact motivation behind us proposing solutions to address the broader use case of trust anchor negotiation in TLS. The primary purpose of trust anchor negotiation is the same as the broader TLS parameter negotiation problem: allowing client and server to agree on a mutually-satisfiable decision when configurations differ, but overlap. Additionally, in a world in which trust anchor negotiation exists, there is the possibility of improving upon existing TLS PKI pain points exacerbated by its absence. There are existing solutions that address a subset of these pain points. Combining these together risks increasing complexity beyond a single more complex solution and introduces possible undefined behavior, unexpected failure modes, etc. There are also solutions that are theoretically capable of solving the broader problem, but with barriers to viable deployment (such as certificate_authorities). I am deeply sensitive to the pitfall of adding extensibility for extensibility's sake and feel that the complexity of TE and TAI are a result of different tradeoffs, of which the WG may prefer one over the other. As David Benjamin noted, TE pushed complexity away from TLS clients and servers and towards root programs and CAs, which are both fewer, and have a well-formed existing relationship. TAI, on the other hand, is able to be more simply specified at the cost of adding additional dependencies, such as maintaining fresh and accurate DNS records. On the whole, we hope the WG will review both proposals and let us know which set of tradeoffs we collectively prefer so that we can standardize and deploy a viable negotiation mechanism. -Devon
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
