[TLS] Re: draft-ietf-tls-trust-anchor-ids-00

[David Benjamin <[e-mail]>]

Hi Luke! Thanks for the thoughts!

I don't remember if there was a particular reason originally, probably just
an artifact of them being in separate sections. :-) Reusing it makes sense,
although there are some differences here:

Regarding mismatching signatures and whatnot, the original thinking with
the EncryptedExtensions retry was that the server would filter the list
down based on all its other selection criteria. If the server knows the
client doesn't support ECDSA, there is no point in saying you have a trust
anchor that has only signed an ECDSA key. The server already has all that
information available by way of the ClientHello. But it looks like we
half-forgot to write that. (Half because there's one sentence that only
makes sense if the text were there, but the text itself is missing.) I
filed a bug to track this:
https://github.com/tlswg/tls-trust-anchor-ids/issues/97

Assuming the WG ends up sticking with that design, that should avoid the
sigalg issues described in Section 5.3, but not things being out of sync if
you got routed to a different server instance. In that case, yeah, I could
see the client wanting to offer a couple of them a la Section 5.3. (Though
there are other ways to solve this, including the client trying a couple
times or an in-handshake retry. This is basically the same problem space as
in the ECH retry, except that we can offer multiple and ECH cannot.)

If we go with the client offering multiple options, there is an added input
to the procedure: did the client like the *particular certificate* that the
server already presented? If not, the client may want to specifically
exclude that trust anchor in the retry and use this mechanism as a way to
iterate over what the server has. This can be useful in corner cases when
the client imposes custom policies like SCTNotAfter[0] or name-constraining
a trust anchor, e.g. as part of a partial distrust. While those are broadly
invisible, you can hit a corner case if *all* of the following happen:
- The client has put some trust anchor under a constraint
- The server has some certificate A from the trust anchor that breaks the
constraint (and is thus not useful to the client)
- But certificate A may be useful to some *other* client (e.g. an older
one), which is why the server still wants to keep getting certs from the
trust anchor for now. (I'm very interested in helping server operators
de-risk configuration changes as PKIs evolve, and being able to retain your
previous cert profile while transitioning in your new one helps do that.)
- The server has some certificate B from some other trust anchor that would
satisfy the client
- For some reason, when offered both, the server picked A instead of B

In that case, the client might say "well, you have A and B available, but
you gave me A and I see now that that is unacceptable, let me try again
asking just for B". The retry mechanism then lets you repair mishaps in
these kinds of complicated corner cases that can arise, without the
complexity of encoding the ad-hoc policies into the protocol. Of course,
the cost is that we repair mishaps with an expensive retry, but as long as
these are exceptional cases, I think that's fine.

To that end, the client here might want to tweak the Section 5.3 behavior
where, if it sees two trust anchors in DNS, one of which it has constrained
and another which it has not, it may wish to only ask for the unconstrained
one to direct the server to pick the one that's more likely to be
acceptable. I.e. only request constrained trust anchors as a last resort.
That should avoid the retry most of the time. The server adjusting its
preference order to put B over A would also avoid it.

(This allowance wasn't actually an original design goal, rather a happy
accident that fell out of inverted selection order. We then also got
feedback from another client that this sort of thing was useful for
something else they were doing, though I don't know the specific details
and wouldn't want to speak on their behalf.)

Anyway, clearly the draft should give some more guidance here. To go full
circle, more guidance means more reason to share the underlying text
sections so we don't have to write similar guidance twice. I'll file a bug
referencing this thread to keep track of all this. :-)

David

[0] https://dadrian.io/blog/posts/sct-not-after/


On Tue, Mar 11, 2025 at 11:10 AM Luke T2 <[e-mail]> wrote:

> Hey David,
>
> Thanks for the draft! I had some thoughts about how Relying Parties build
> their list of Trust Anchor IDs to send to the Authenticating Parties. In
> the draft currently there is different behaviour by the Relying Party
> depending on whether it is a retry connection or not.
> When a relying party receives the tls-trust-anchors in the DNS Service
> Parameter they compute the intersection of the received trust anchors with
> their configured trust anchors, then they use that information to determine
> their trust_anchors list - in this case relying parties should offer
> multiple options.  In the other case, when retrying a connection, relying
> parties should choose a single Trust Anchor ID from the EncryptedExtensions
> to send.
> Could you talk me through your reasoning for the different mechanisms?  I
> would suggest using the same mechanism for calculating the trust_anchors on
> retry as when using the DNS Service Parameter, so the client has consistent
> behaviour and then the authenticating party has the final choice of the
> certificate chain to serve.
> Otherwise, the issue described in Section 5.3 of the draft could occur on
> retry with the client picking a trust anchor which includes a certificate
> in the chain it doesn’t support the signature for.
>
> Cheers,
> Luke
>
>