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