On Tue, Sep 24, 2024 at 8:19 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> On Tue, Sep 24, 2024 at 5:07 PM Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > <snip> > > > > > > Could you elaborate on how a long list could result in a failure or add > > > complexity? > > > > Again, I'll try:-) > > > > Let's say we have targets T1 and T2. And server instances S1, S2 > > where T1 is served by both S1 and S2 but T2 only by S2. > > > > T1 is an ordinary thing and it's best list to publish is the usual > > good thing we'll call L1. T2 however is a special and has some oddball > > clients that need to use oddball groups and so has a supported (or > > preferred:-) list that's L1+oddballs. > > > > If we publish L1+oddballs for T1 and the CH is sent to S1 then we > > will see a fail if a T1 client happens to prefer an oddball group. > > > > In that case ISTM the right thing is to publish L1 for T1 and > > L1+oddballs for T2. > > > > Publishing L1 for T1 doesn't seem to me to represent publishing > > the list of supported groups, as S2 can in fact handle more. > > You've forgotten SNI. The support by server can also vary by target, > not just the physical box or IP that gets hit by the connection (and > that IP may itself be dependent on L not just S). But I agree, > supported may have the wrong connotation as compared to what we want, > which is the list in preference order that the server will accept. > Varying by SNI just means that S2/T1 and S2/T2 are actually two different service endpoints that happen to share a physical box and IP. It's very easy to capture that in DNS because the DNS query already tells you whether you're looking up T1 or T2. If T1 and T2 are served by different kinds of service endpoints, serve different HTTPS/SVCB records for them. Specifically, T1 should serve an HTTPS-RR for S1/T1 with S1/T1's properties and one for S2/T1 with S2/T1's properties. T2 should serve an HTTPS-RR for S2/T2 with S2/T2's properties. (See my reply to Stephen for the rest of how this situation is resolved, and TLS's long-standing precedent in the naming.)
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
