[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[David Benjamin <[e-mail]>]

On Tue, Jul 23, 2024 at 11:10 AM Watson Ladd <[e-mail]> wrote:

> On Tue, Jul 23, 2024, 11:04 AM Salz, Rich <rsalz=
> [e-mail]> 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