Hiya,
On 9/25/24 00:07, David Benjamin 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 reckon I fully agree with the goal, but am concerned that the presentation syntax is what people will start from when deciding what to publish in the DNS.
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.
Not precise != not right - but it's entirely fair you try force me to also be precise:-) I'll try below...
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.
I agree with the "best shot" goal. "Full preference list" still seems ambiguous and not the same as supported.
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?
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. My guess is the emerging PQ-zoo plus how that zoo maps to geographies (and hence data centres) may lead to such issues. I could well be wrong of course.
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'm fine with any presentation syntax name that reflects what is in the end the desired semantic including ambiguity. Or with some text that says that even if the name is "tls-supported-groups" that's not what we really mean. The latter seems undesirable though, but if there were a bunch of code-bases already using "tls-supported-groups" or zones that had published such, then weasel-wording around that may be the right answer. (I'm not aware that that's the case, so I think it may be timely to try address this before allocating a codepoint.)
I think the right solution here is honestly to not worry about it too much.
Perhaps. Or maybe we should worry just the right amount:-)
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.
I don't think any change to the wire protocol is needed. I do think changing the presentation syntax name used may help avoid future problems if e.g. someone reads "supported" and figures that means they ought add all the mappings to TLS codepoints they can envisage from what the get running the `openssl ecparam -list_curves` command. Cheers, S.
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 orderofdecreasing 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
