> We should reap what we sow and just use supported_groups Agreed 🥲
On Wed, Sep 25, 2024 at 10:54 AM Bob Beck <bbe=40google....@dmarc.ietf.org> wrote: > > > On Tue, Sep 24, 2024 at 5:12 PM David Benjamin <david...@chromium.org> > wrote: > >> I should add, another reason to call it tls-supported-groups is that this >> is essentially what the server would have put in the supported_groups >> extension, if negotiation order in TLS were inverted. Since TLS already saw >> fit[*] to name this concept supported_groups, I think that's a fine name >> for the equivalent DNS incarnation. >> > >> David >> >> [*] Mind you, supported_groups is a horrible name, but because of >> "groups", not "supported". It refers to Diffie-Hellman groups, but we're >> sticking PQ KEMs in there now. But we already disruptively renamed "curves" >> to "groups" and another rename would do it again. Honestly, we should have >> just kept it at "curves", and saved our disruption budget for a >> more appropriate name, but so it goes. :-) >> > > ^^^ This. having a third term to attempt to describe a concept because > we keep changing our minds is not going to help implementers, but just > cause confusion > > I don't personally like supported_curves^Wgroups but turning that into > supported^Wpreferred_curves^Wgroups^Wkems is just adding confusion and > possibly code churn for variable renaming. We should reap what we sow and > just use supported_groups > > If we absolutely must name the DNS thing something else, treat it as an > opaque list of strings and don't be opinionated about what those > strings contain. The DNS doesn't know or care anyway. name it for what it's > purpose is (keyshare_hint). > > > >> On Tue, Sep 24, 2024 at 7:07 PM David Benjamin <david...@chromium.org> >> wrote: >> >>> 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 >> > _______________________________________________ > 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
