On Tue, Jul 23, 2024 at 11:10 AM Watson Ladd <watsonbl...@gmail.com> wrote:
> On Tue, Jul 23, 2024, 11:04 AM Salz, Rich <rsalz= > 40akamai....@dmarc.ietf.org> wrote: > >> I don't think its possible to go one API / method at a time. If we want >> to turn on a feature by default, it has to either be non-backwards >> compatible or not break any existing API. >> >> I think I agree with you, or at least as far as saying that we really >> need to hear from implementors as to the feasibility of doing this in a >> backward-compatible and generic (not just browser/WebPKI) way. >> > > Applications that don't support aren't worse off because other > applications can use a newer PKI with fewer problems. > Right, incremental deployment is still valuable. Every client that is removed from the fallback case is one less client that constrains the fallback's intersection, and one more client that can evolve unburdened. We've tried to be clear on this from the beginning, and haven't ever claimed to be targeting 100% automatic client deployment. Very few things done by this WG depend on or target that. Of course, making things easier to deploy is always welcome. As with any other work we do in this WG, that's often very dependent on the very specific implementation details and what layer of the stack one works at. ECH, at the level of most TLS libraries, required quite a few caller changes. At the level of HTTPS libraries, however, it can plausibly be done automatically. There's also a wide range of deployment ease, ranging from your TLS library doing it automatically, to needing to opt-in to avoid a couple API interactions specific to one implementation, to callers needing to make a couple simple decisions, to callers needing to make some very complex decisions. Indeed part of why we've presented the second draft is that they represent very different deployment tradeoffs. And even within a broad solution direction, there are a lot of decisions that impact this. For example, client ease of use for draft-beck-tls-trust-anchor-ids will change dramatically depending on whether we use a separate connection (a la ECH) or a retry in the handshake (a la HRR, though we might not want it to be *exactly* HRR, we'll see). We wrote up the former just because it was a simpler representative of the overall idea. This all sounds like an excellent topic to continue discussing through post-adoption. As with other IETF work at this stage, our goal here isn't to present a complete solution, but to present a problem to solve, and some starting points for the WG to build on. David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
