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 _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
