Ah, I see. I don't think "supported" vs "preferred" captures this because "preferred" in the context of TLS usually isn't a binary property but a preference order. But I agree there is some ambiguity over what to list if you've got a couple different values.
I think, other than potentially changing the name, it's not likely that this will have any impact on the presentation syntax. At the end of the day, we're going to want to send a list of things that your service (being intentionally vague about multiple server instances) supports. But since "supported" vs "preferred" is not the right descriptor, I suspect we won't do better than "supported" anyway. In particular... > I interpret preferred as being a list that the target thinks > will help clients avoid HRR, and help clients choose what is > considered "best" (e.g. wrt PQ) and that should work with all > server instances concerned, and that's likely the shortest > such list. That's not right. Avoiding HRR is a matter of predicting the group that the server would have picked given yours and the server's preferences. For example, consider a server that supports: A > B > C > D > E > F By the short list theory, you might think the server should publish, say, "A, B, C". However all that accomplishes is that a client that only supports D, E, and F won't know that it should predict D. The right behavior is to publish your full preference list, so that all clients (up to differences in selection algorithm) have the best shot of predicting correctly. > The issue with "supported" may be that some server instances > might have support for all sorts of oddball groups, and it > might be counterproductive to list all of those for the > target. (And/or to collect/merge the list if we're thinking > about e.g. the wkech thing.) Variations in server instances may indeed result in mispredictions. If the variation is due to a temporary rollout inconsistency, this variation is shortlived and will eventually sort itself out. During that period of inconsistency, neither list is more correct than the other because you want to make the correct prediction for each server. If the variation is persistent because you've intentionally deployed different instances of your service differently... first of all, don't do that. The security properties are not what you might. (An attacker can always direct the client to the weaker of the two.) If, despite the security flaws, you insist on doing this, I suppose you can use different HTTPS records for each and use all the machinery that HTTPS-RR already has here. That's all orthogonal to this draft because describing multiple routes to a single service is a general HTTPS-RR feature. > I'm fine that the text is a bit ambiguous on that for now, but > if the presentation syntax says "supported" then someone may > take that literally and publish very long lists that could > result in failures, for some server instances. (Or else could > add complexity in how e.g. a front-end thing like haproxy has > to process client hellos.) Could you elaborate on how a long list could result in a failure or add complexity? At the end of the day, all this does is influence what key shares the client predicts. No matter which group the client predicts, the client remains obligated to send a ClientHello that accurate describes its preferences, and the server remains obligated to interpret it according to the rules of RFC 8446. That is all baseline requirements in implementing TLS 1.3 that this working group long decided on. If the result is that the client predicted well, great. We get better performance. If the result is that the client predicted badly, well, that's a shame but the server is already required to correctly send HelloRetryRequest. That is not added complexity or a failed connection because HelloRetryRequest is a required part of RFC 8446. Indeed Section 3.4 of the draft explicitly says that this cannot guarantee you won't get HRR. As in RFC 8446, you remain obligated to fully implement TLS 1.3, including HRR. No DNS-based design can get rid of HRR because DNS and service instances can always get out of sync. That has never been the goal here. All we can do is reduce the cases where it happens. > I think a presentation syntax of "tls-preferred-groups" would > fix the issue. Hopefully the above makes it clear that the rename both would not fix the issue, and doesn't really reflect the semantics we need here. I think the right solution here is honestly to not worry about it too much. Maybe we could add a bit of text to point this situation out, but otherwise I don't think there's anything we can or should change in the protocol itself. At transition points, it is already inevitable, due to DNS caching, that you'll get out of sync. That's fine. TLS 1.3 already handles that. Whether DNS servers the new or old population of servers isn't really going to change that. We could maybe include a suggestion to pick like the majority one or something, but it doesn't hugely matter. David On Tue, Sep 24, 2024 at 6:49 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > On 9/24/24 23:36, David Benjamin wrote: > > Could you clarify what you mean by supported vs preferred? I'm not sure I > > follow what the difference is, in the context of a TLS implementation. > > I can try:-) > > > The intention is that you list all the NamedGroups you support, in order > of > > decreasing preference. That gives the client enough information to make a > > reasonable prediction. > > I interpret supported as being the set of all groups that could > work with either all or at least one of the server instances > currently listening at the target's IPs. (I don't think the draft > says which of "all" or "at least one" is the intended semantic.) > > I interpret preferred as being a list that the target thinks > will help clients avoid HRR, and help clients choose what is > considered "best" (e.g. wrt PQ) and that should work with all > server instances concerned, and that's likely the shortest > such list. > > The issue with "supported" may be that some server instances > might have support for all sorts of oddball groups, and it > might be counterproductive to list all of those for the > target. (And/or to collect/merge the list if we're thinking > about e.g. the wkech thing.) > > I'm fine that the text is a bit ambiguous on that for now, but > if the presentation syntax says "supported" then someone may > take that literally and publish very long lists that could > result in failures, for some server instances. (Or else could > add complexity in how e.g. a front-end thing like haproxy has > to process client hellos.) > > Section 3.2 maybe encapsulates the ambiguity: > > "Services SHOULD include supported TLS named groups, in order of > decreasing preference in the tls-supported-groups parameter of their > HTTPS or SVCB endpoints. As TLS preferences are updated, services > SHOULD update the DNS record to match." > > The 2nd sentence could be read as referring to the ordering or > to the content of the list. And the example would indicate the > latter. (To me anyway.) > > I think a presentation syntax of "tls-preferred-groups" would > fix the issue. > > Cheers, > S. > > > > > On Tue, Sep 24, 2024 at 6:24 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> I read the draft again just now. ISTM overall a fine idea. > >> > >> I think the current draft is a bit ambiguous as to whether > >> the SvcParamKey reflects preferred or supported groups. It > >> may be better to resolve that before allocating a codepoint. > >> > >> However, if the DEs considered a possible later change to the > >> presentation syntax as being consistent with allocating a > >> codepoint now, then I'd be fine with going ahead now, but IIRC > >> DNS folks do also care about presentation syntax stability > >> when it comes to codepoints. (I could be wrong there or things > >> could have changed, which could change my conclusion.) > >> > >> The quickest way to resolve this might be to rev the draft > >> and just change the presentation syntax term from supported > >> to preferred. (Assuming we agree that the HTTPS RR values > >> will typically reflect overall group preferences for the > >> target and not everything actually supported by all the > >> server instances concerned.) > >> > >> Cheers, > >> S. > >> > >> On 9/24/24 19:17, Sean Turner wrote: > >>> Hi! After discussions with the author (David Benjamin) of draft-ietf- > >>> tls-key-share-prediction [0], I would like to determine whether > >>> there is consensus to request an “early” * code point request for a > >>> 'tls-supported-group' entry in the Service Parameter Keys registry; > >>> see Section 5 of the I-D. The point of this consensus call is to > >>> determine whether you think this I-D is stable enough to request a > >>> code point in the Expert Review range [1]. Please let the list know > >>> by 8 October 2023 if you support this “early" allocation. > >>> > >>> * Early is in quotes because, technically, this is not an early IANA > >>> allocation as defined in [2]; I am just calling it “early" because > >>> it’s before the I-D is an RFC. I confirmed with the Service > >>> Parameter Keys DEs (Designated Experts) that we can get a code point > >>> in the Expert Review space if the I-D is stable; if not, then we > >>> should be using the Private Use space. > >>> > >>> spt > >>> > >>> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-key-share- > >>> prediction/ [1] https://www.iana.org/assignments/dns-svcb/dns- > >>> svcb.xhtml [2] https://datatracker.ietf.org/doc/rfc7120/ > >>> _______________________________________________ TLS mailing list -- > >>> tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org > >> > >> _______________________________________________ > >> TLS mailing list -- tls@ietf.org > >> To unsubscribe send an email to tls-le...@ietf.org > >> > > > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
