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
