On Wed, Dec 18, 2024 at 02:14:50PM -0800, Devon O'Brien wrote: > We have cut a new -03 version of the Trust Anchor Identifiers draft: > > URL: > https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-03.txt > > Status: https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/ > > HTML: > https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-03.html > > While we didn’t get any mic time in Dublin to present the updates since our > presentation in Vancouver, we had several conversations with attendees and > have incorporated some suggested changes as a result.
Some issues I have been thinking about (this all concentrates on server certificates): 1) Certificate chain mismatches between services on the same server: Trust Anchor IDs uses ServiceMode HTTPS/SVCB records to store list of available roots in DNS. These are logically per (logical) server. However, the available roots may differ between two services that are pointed to the same server via AliasMode HTTPS/SVCB records. Especially if considering intermediates as roots for intermediate elision (e.g., Let's Encrypt randomly issues off two intermediates). Furthermore, ECH adds another implicit service to every server in order to update ECH keys or to disable ECH. 2) Load-balancing certificate flip-flop: If server is load balanced, reconnects may go to different server, which might be out of sync with the previous server. As consequence, root lists from previous connection might not be correct for reconnection (especially intermediates). Just because some service has one IPv4 and one IPv6 address does not mean there might not be plenty of flip-flop with updates. 3) Connections racing with certificate changes: Even without load balancing, the root lists might change between reconnections (especially intermediats). Servers usually withdraw certificates suddenly with no grace period. In server software of capable of hot-reloading certificates, such races could even occur between sending HRR and client retrying. 4) How to repair mismatches: I think that the only feasible way to repair mismatches on server side would be to use HRR (regardless of any potential bad interactions with ECH). I think altering the TLS state machine for adding a new optional pair of flights would be far too big change. And since reconnects can not be transparent, those are no-go for many uses. Including ones that would benefit a lot from trust anchor negotiation. I don't think there is a fourth way. And reconnects can pile up exponetially: - Client tries with bad ECH, bad trust anchors, server fixes trust anchors. - Client tries with bad ECH, good trust anchors, server fixes ECH. - Client tries with good ECH, bad trust anchors, server fixes trust anchors (for different service!). - Client tries with good ECH, good trust anchors. This succeds. Then reconnects also bypass some TLS 1.3 downgrade protections. The client has to be very careful not to introduce downgrade attacks in the process. Furthermore, no authentication of any kind is possible here, so the previous connection might have been to an attacker. 5) Client filtering of IDs: Intermediate elision presumably requires including Trust Anchor IDs for intermediates, and that presents some special considerations. I presume that intermediate IDs should not be included without having an root ID the intermediate chains to. And where CA used is known to have unpredictable/backup issuers, or rotate issuers, it could be useful to include related issuers even if the server does not signal those (it is just a few dozen bytes at most, I think the 5-set Let's Encrypt uses is exceptionally large). Then some ideas: - If Trust Anchor IDs fails to negotiate a certificate, it should just be ignored. That is, fall back to whatever processing would happen without the extension. Server should not explicitly fail unless it requires trust anchor negotiation, and is just plain incompatible with clients that do not support it. - Send all the issuer chains in every (extended) ACME response, or have dedicated endpoint to download the issuer chain bundle per issuer. This avoids having ACME client combine multiple chains from alternatives. Which is not as easy as it sounds because the EE certificates can differ, which can lead to really bizarre edge cases. Having bundle of issuer chains also fits a lot better with the configuration model of a lot of existing TLS server software. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
