[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

[Ilari Liusvaara <[e-mail]>]

On Sat, Jul 27, 2024 at 06:56:17PM -0700, Dennis Jackson wrote:
> On 26/07/2024 15:24, Sophie Schmieg wrote:
> 
> > I don't think trust anchor negotiation needs a lot more discussion, over
> > what has happened already. All in all, I think it's a good mechanism
> > that is fairly well defined and it's not clear to me how it would
> > benefit from an interim.
> 
> The Trust Anchor Identifiers draft was first published only 4 weeks ago,
> received less than 10 minutes of discussion in the meeting and has a lot of
> unaddressed issues.
> 
> As I noted, many participants in the meeting expressed a preference for an
> interim so I would be surprised if there was support for adoption.
> Especially as the concerns I want to present are fundamental to the design
> rather than about issues which could be addressed later.

Another concern with TAI is its interaction with ECH.

- Currently, the draft retries the entire connection on failure. The
  worst-case number of connection attempts required is exponential in
  number of extensions that do whole-connection retries. Since ECH
  does that, TAI+ECH can require up to four connection attempts.

- For another correction mechanism, only HRR seems feasible. All the
  others would require modifying very sensitive places in TLS, which
  would require very careful analysis. Worse, such mechanisms would
  also alter handshake state machine, which could have severe impact
  on implementations.

  However, using HRR might not resolve the whole problem, because ECH
  might have some residual issues with anything that triggers HRR.


Another major concern with retrying entire connection on failure is
requiring major API changes on client side, in turn requiring major
application changes (outside things like HTTP client libraries,
which could encapsulate the changes).

In comparison, interface to give advice from DNS (even if it
requires application changes) is much more minor modification.
 
Even minor-looking things (e.g., asynchronous handshake signing) can
have major API implications.




-Ilari