[TLS] Re: -03 update to draft-beck-tls-trust-anchor-ids

[Ilari Liusvaara <[e-mail]>]

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