On Fri, Jan 26, 2024 at 5:15 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Jan 25, 2024 at 05:00:19PM -0500, David Benjamin wrote: > > > > Second, I wanted to take a step back and try to better articulate our > > goals. I think the best way to look at this draft is in three parts: > > > > 1. A new multi-certificate deployment model (the overall goal) > > > > 2. Selecting certificates within that model (the TLS parts of the draft) > > > > 3. Provisioning certificates (the ACME parts of the draft) > > I think a bit differently: > > a. What information does the server have, what information it > dynamically receives from the client? > > b. How does this drive certificate chain selection? > > c. How the information from client is encoded? > > d. How the information server has is provisioned? > > > The reason for splitting it this way is that b., c. and d. are all > important problems, all three depend on a., but only b. and c. are in > remit of TLS. Oh, and I regard d. as formidable challenge, by far the > most difficult part. > Ah sure. I was mostly thinking a step before that split. From Prague, I got the sense it'd be useful to focus the initial discussion about why a multi-certificate model is useful, and perhaps the high-level shape of the solution, separate from hashing out the protocol details. I suspect if "what are we trying to do and why" vs "here's how to provision the server" are lumped into one discussion thread, it'll be very difficult to keep track of things. Also the former seems more useful for questions like whether to adopt, while the latter seems like something we can hash out later. Beyond that, my division between 2 and 3 was perhaps a bit sloppy there, yeah. I was just trying to capture that we've been focusing a bit less on the ACME bits for now. Not because they aren't important or tricky, but because I think they're not *strongly* impacted by the rest of the design. "Some way to get multiple certs" and "some metadata to attach to the certs" is a pretty general thing to design for. Maybe some variability around whether we need to believe metadata update and certificate refresh are the same operation or different. Anyway, this is just me giving my best attempt at organizing the discussion a bit. It's a pretty large problem and design space to navigate without some framing. But if other corners catch people's eye instead, I'm happy to discuss whatever. :-) > > We’d most like to get consensus on the first, as it’s the most important. > > Trust expressions are a way to achieve that goal, but we’re not attached > to > > the specific mechanism if there’s a better one. > > Well, I certainly do not have ideas for solving the problem that are > dramatically different from what is in there currently. > > > > The aim is to get to a more flexible and robust PKI, by allowing servers > to > > select between multiple certificates. To do this, we need a way for the > > servers to reliably select the correct certificate to use with each > client. > > In doing so, we wish to minimize manual changes by server operators in > the > > long run. Most ongoing decisions should instead come from TLS software, > > ACME client software, and ACME servers. > > The thing that makes provisioning challenging is that there is fourth > party involved: Application terminating TLS on server side. > > I am not aware of any current (I know one that existed in the past) > deployments that have ACME client software directly interface with TLS > software. > > And I have never encountered application configuration interface I could > easily see how to make it work with something like this. Most because > certificate lists are either static or unordered. > > A more reduced scope that is likely feasible with more applications is > selecting among chains for single end-entity certificate. However, such > restrictions do not affect the TLS-visible parts. > Yeah the ACME client <-> server configuration interface is definitely on the interesting side. I think it's more important to preserve the graph of what components talk to each other (i.e. the operational considerations), than to preserve the exact interfaces between them. Obviously, the less we have to change, the better, but I think it's also okay to have to extend those interfaces if push comes to shove. And yeah, reduced-scope versions for some cases could also be useful. Although the single-leaf restriction does remove a lot of the flexibility that we'd otherwise afford the server operator, so I think we should still design for the general case. In particular, I think these reductions not only don't have to affect the TLS-visible parts but also most of the ACME-visible parts either. Unless I've just missed it, ACME itself does not specify how the certificates make their way into server software. The ACME client can always filter out any certificates the particular TLS software cannot handle. The ACME client can freely transform its output to whatever the other end wants. If ACME hands back multiple PEM bundles[*], but a single combined structure would be more convenient for some server software, the ACME client can just combine them. Configuration interfaces are ultimately deployment-specific anyway. Some servers just store their private keys in files next to their certs. Other servers may do some private key offload. Their configuration interfaces will be very different. [*] We're not attached to the current multiple bundles thing, to be clear. Just an example. :-) > > Why does this matter? PKIs need to evolve over time to meet user security > > needs: CAs that add net value to the ecosystem may be added, long-lived > > keys should be rotated to reduce risk, and compromised or untrustworthy > CAs > > are removed. Even a slow-moving, mostly aligned ecosystem is still made > of > > individual decisions that roll out to individual clients. This means, > > whether we like it or not, trust divergence is a fact of life, if for no > > other reason than out-of-date clients in the ecosystem. These clients > could > > range from unupdatable TV set-top boxes to some IoT device to a browser > > that could not communicate with its update service. > > Or worse, SCADA systems. Unupdatable *and* very long-lived. > Yup. And in those environments, that may well be a reasonable choice! I don't work on SCADA, so I can't really say much. But the Web has different needs, and if you're a server that straddles both kinds of environments, you will have a hard time today. > > Now, some of these problems can be addressed with cross-signs between > CAs, > > but this is a partial solution at best. Without negotiation, this still > > means sending certificates for the lowest common denominator to all > > clients. This wastes bandwidth, particularly with post-quantum > > cryptography, where every signature costs kilobytes. Additionally, an > > individual server operator cannot unilaterally configure this. > Cross-signs > > apply to entire intermediate CAs, not just the individual server’s > > certificate. > > Also, having certificate negotiation lets one in most cases drop > intermediates, saving a chunk of bandwidth (e.g., Let's Encrypt RSA > intermediate is 1306 bytes.) > > > > > -Ilari > > _______________________________________________ > 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
